Technical
OAuth
OAuth is an authorisation framework that lets an app act on a user's account at another service through a limited token, without ever receiving the user's password.
How it is measured
Watch the redirect flow. The browser goes to the provider's `/authorize` with `client_id`, `redirect_uri`, `scope`, and `state`. The user consents, the provider redirects back with a `code`, and the app's server exchanges it at `/token` for an access token. Read the granted scopes and `expires_in` in that response.
Verify that `state` matches what you sent and that `redirect_uri` is exactly one you registered. The provider's console lists authorised apps and when each token was last used.
Worked example
A scheduling tool asks a calendar provider for read-only access. The user approves, and the tool receives an access token valid for 3,600 seconds plus a refresh token. A bug first requested full calendar access, and 3 of 40 testers declined at the consent screen.
Narrowing the scope to read-only changes the consent text, and acceptance rises to 38 of 40. When a user revokes the tool in the provider's settings, its next call returns 401.
How it differs
OAuth is the process of getting a token. A JWT is one format that token can take. OAuth tokens can be opaque strings with nothing readable inside. OAuth says who may do what, and the JWT is only a container.
Common errors
Skipping the `state` check. Matching redirect URIs loosely. Requesting more scope than needed. Putting the client secret in a mobile app or single-page app. Using OAuth as a login system, which is what OpenID Connect adds. Storing refresh tokens in plain text.
In practice
List what each integration requests and cut scopes to the minimum. Register exact redirect URIs, check `state`, and use PKCE for public clients. Review authorised apps every quarter and revoke the unused ones.