OAuth ultimately revolves around tokens: compact artifacts that represent a delegation from a resource owner to a client for a protected resource. Authorization servers mint access tokens (and optionally refresh tokens), clients treat tokens as opaque, and resource servers validate and apply the associated rights. The core specs deliberately leave token format unspecified, enabling deployments to choose opaque, database-backed handles or self-contained, structured tokens, with varied expirations and revocation behaviors. Regardless of format, resource servers must verify who issued the token, who it’s for, when it’s valid, and what scopes it conveys.
Structured tokens are commonly implemented as JSON Web Tokens, which encapsulate claims such as issuer, subject, audience, expiration, and unique identifiers in Base64URL-encoded JSON. Because an unsigned JWT is easily forged, deployments protect tokens with the JOSE family: signing (JWS) and, when necessary, encryption (JWE). Signatures can be symmetric (for closely coupled systems) or asymmetric (authorization server signs with a private key; resource servers verify with the public key, often distributed as JSON Web Keys or fetched via a published key set). Proper verification uses the exact received token bytes and checks signature, issuer, audience, and time-based claims; clients remain agnostic to all of this.
When tokens need server-side state or real-time status, resource servers can call a token introspection endpoint to learn whether a token is active and retrieve details like scopes, client, and user—typically with short-lived caching to balance performance and revocation responsiveness. Introspection pairs well with JWTs: a resource server can perform basic local checks from the JWT, then introspect for richer or sensitive data and revocation state. To complete the lifecycle, the token revocation endpoint lets clients proactively invalidate access and refresh tokens; responses avoid leaking information about other parties’ tokens while ensuring the client discards its own. Together, structured tokens, cryptographic protection, introspection, and revocation provide a flexible toolkit for secure, scalable OAuth token management.
The unofficial OAuth logo, modeled after a bus token
Connecting the protected resource to the authorization server
The client’s homepage with a control to trigger token revocation
The OAuth token lifecycle
FAQ
What is an OAuth token and why is it central to OAuth?
It is a credential issued by the authorization server to a client and presented to a protected resource. It represents the result of delegated authorization (who authorized what, to whom, for which resource, with which scopes, and for how long). Without tokens, OAuth has nothing to convey authorization decisions.Why doesn’t OAuth define a single token format?
To maximize flexibility. Deployments differ in risk, scale, and requirements. Tokens may be opaque or structured, short‑lived or long‑lived, revocable or not, and may be protected in different ways. Only the authorization server and resource server need to agree on the format; clients treat tokens as opaque.What’s the difference between access tokens and refresh tokens?
- Access token: Presented to the protected resource to access APIs until it expires or is revoked.- Refresh token: Held by the client and exchanged at the authorization server for new access tokens without re‑prompting the resource owner.
What is a JWT and how is it structured?
A JSON Web Token is a compact, URL‑safe token format: header.payload.signature. The header and payload are Base64URL‑encoded JSON. The header declares typ/alg; the payload holds claims (for example iss, sub, aud, exp). The signature (in JWS) protects integrity; an unsigned JWT (“alg”: “none”) is not secure.Which standard JWT claims are commonly used and what do they mean?
- iss: Issuer (who created the token)- sub: Subject (who the token is about)
- aud: Audience (who should accept it)
- exp: Expiration time (seconds since UNIX epoch)
- nbf: Not‑before time
- iat: Issued‑at time
- jti: Token ID (unique identifier to prevent replay)
Why use Base64URL encoding in JWTs?
It makes tokens safe to place in HTTP headers, form/query parameters, and logs without additional encoding. It also avoids middleware re‑serialization issues, so the exact byte sequence can be verified during signature checks.Why are unsigned JWTs dangerous, and how does JOSE protect tokens?
Without protection, a client could alter or fabricate token contents. JOSE provides: JWS (signatures) to ensure integrity and authenticity; JWE (encryption) to keep claims confidential; and JWK/JWKS for key representation and distribution. Always verify signatures on the exact token string received “on the wire.”When should I use HS256 (symmetric) vs RS256 (asymmetric) signatures?
- HS256: Authorization server and resource share a secret; simple but both can mint tokens if compromised, and key distribution/rotation across many resources is hard.- RS256: Authorization server signs with a private key; resources verify with the public key. Easier key distribution/rotation, and verifiers cannot mint tokens. Public keys can be published via JWKS.
OAuth 2 in Action ebook for free
