Security Glossary

OAuth2 Access Token

A credential issued by the authorization server that grants the client limited access to protected resources on behalf of the user.

OAuth2 Access Token is the credential a client presents to a resource server to reach protected data on the user's behalf. It encodes a delegated grant, scoped and time-limited, and is deliberately narrower and shorter-lived than the user's own login session.

JWT vs Opaque: Self-Contained vs Reference

  • JWT access token: a signed token that carries its own claims (iss, aud, exp, scope, sub). The resource server validates it locally with no call back to the issuer.
  • Opaque access token: a random reference string with no readable content. The resource server (or the client) resolves it by calling the authorization server's /introspect endpoint.

The trade-off is revocation vs cost: a JWT is valid until it expires even if access is revoked; an opaque token is checked live but needs a round trip. See OAuth2 Resource Server for how each is validated.

Token Response

POST /token
// ->
{
  "access_token": "eyJhbGciOiJSUzI1NiIs...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "dGhpcyBpcyBhIHJlZnJl...",
  "scope": "read:profile write:profile"
}

Claims That Constrain the Token

  • aud names the resource server the token is for. It is the check that stops a token minted for one API being replayed against another.
  • scope lists the operations the token authorizes; the resource server enforces it per endpoint.
  • exp caps the lifetime. Keeping it short (minutes to an hour) limits how long a stolen token is useful.

Short Lifetime and Refresh

Access tokens are kept short-lived precisely because they travel to resource servers on every request and are hard to revoke mid-life. When one expires, the client uses a longer-lived refresh token, held more securely and never sent to resource servers, to obtain a new access token without involving the user again.

Bearer Tokens and Theft

By default access tokens are bearer tokens: possession is sufficient, so anyone who captures one can use it until it expires, with no proof of who they are. That makes exposure the dominant risk:

  • A token in a URL leaks through Referer headers, browser history, and server logs; keep it in the Authorization header, never the query string.
  • In a browser app, a token reachable from JavaScript is stealable by any XSS; storing it in localStorage maximises that exposure.
  • Always transmit over HTTPS so it is not sniffed in transit.

Sender-Constrained Tokens

To remove the bearer weakness, the token can be cryptographically bound to the client that requested it, so a stolen token is useless without the client's private key. DPoP (an application-layer proof, RFC 9449) and mTLS-bound tokens (RFC 8705) are the two standard mechanisms.

See Also