OAuth 2.0

RFC 6749 section 2.1 types a client on one property: whether it can keep its credentials confidential. Server-side code can. An installed mobile app cannot, so it is public — a secret shipped inside it is readable by whoever installs it.

The resource owner's password is a credential shared only with the authorization server, the party they already have an account with. That server authenticates the owner itself and issues the client a separate credential, an access token, which the resource server validates.

RFC 6749 defines four roles: the resource owner who grants access, the client that asks for it, the authorization server that authenticates the owner and issues an access token, and the resource server that holds the data and validates that token.

The scope parameter names the access a client is asking for, as a space-delimited list of case-sensitive strings the authorization server itself defines. Order carries no meaning; each string adds one more access range to the request.

Both carry the same client_secret to the token endpoint. client_secret_basic puts client_id and secret in an HTTP Basic Authorization header; client_secret_post puts them in the form body. RFC 6749 requires Basic support and marks the body form NOT RECOMMENDED.

The authorization code grant keeps the resource owner's password at the authorization server. The user authenticates there, and the client receives only a short-lived authorization code, which it exchanges on a back channel for a scoped access token.

RFC 8252 keeps the authorization request in an external user-agent because an embedded web view runs inside the application: the application can observe what is typed into it, including the resource owner's credentials, and it shares no signed-in session with the browser.

PKCE stops authorization-code interception. An attacker who captures the code as it travels back through the browser cannot redeem it, because the token request must also carry a code_verifier that only the application which started the flow holds.

A slow_down answer means the client must add 5 seconds to its polling interval for this and every later request — a permanent increase, not a one-off pause. Where the response supplied no interval, the client must use 5 seconds.

The device POSTs to the token endpoint with grant_type set to urn:ietf:params:oauth:grant-type:device_code, plus its device_code and client_id. Until the user approves it gets an error response carrying authorization_pending, then a normal token response.

An access token is the short-lived credential a client presents to a resource server for one slice of an account. A refresh token goes only to the authorization server and buys a replacement access token when the access token expires.

active is the one REQUIRED member of an RFC 7662 introspection response, and a true value generally indicates that this authorization server issued the token, it has not been revoked, and the call falls inside its validity window.

expires_in is the access token's lifetime in seconds, counted from when the response was generated - not an absolute time, and not a statement about the refresh token. The lifetime is chosen to balance how long a leaked token stays useful against how often clients must return to the token endpoint.

Revoking a refresh token SHOULD also invalidate every access token issued under the same authorization grant, where the server supports revoking access tokens at all. Revoking an access token only MAY take the matching refresh token with it.

A revocation request is a form-encoded POST carrying the token parameter, an optional token_type_hint, and the client's own credentials. HTTP 200 means the token is no longer usable, and is also the answer when the submitted value was never valid.

Exact string matching is what ties an issued authorization code to the application that asked for it. Any looser rule - prefix, substring or wildcard - lets an attacker steer the response to a destination the client never registered.

The authorization response arrives as query parameters on that URL, and the code in it is a one-time credential redeemable at the token endpoint. Whatever copies the URL - an access log, browser history, a referring header - copies the credential.

The state parameter is an opaque value a client generates per authorization request, binds to that browser's session and checks on the callback. It rejects authorization responses the client never asked for. It proves nothing about which authorization server answered.

A mix-up attack needs a client able to start flows at more than one authorization server. Nothing in a plain OAuth 2.0 authorization response names the server that produced it, so one server's response can be processed as another's.

An attacker can simply omit the parameter. A client must record, per authorization server, whether that server returns iss, and reject a response from such a server when the parameter is missing as well as when it does not match.