Access Token

In the most common OAuth 2.0 pattern, an access token is a bearer token. This means any party in possession of the token can use it to access the associated resources, analogous to a physical key. The security model relies on confidentiality—keeping the token secret during transmission (via HTTPS/TLS) and storage. The resource server validates the token's signature and claims but does not perform additional proof-of-possession checks. This simplicity drives widespread adoption but necessitates robust transport and storage security.

Access tokens are intentionally constrained by two key dimensions:

• Scopes: A token is issued for a specific set of permissions (e.g., read:contacts, write:files). These scopes limit the operations the client can perform, enforcing the principle of least privilege.
• Expiration: Tokens have a short validity period, typically minutes to hours. This limited lifetime reduces the risk window if a token is compromised. A separate, longer-lived refresh token is used to obtain new access tokens without user re-authentication. This combination balances security with user convenience.

Modern access tokens are often encoded as JSON Web Tokens (JWT), a compact, URL-safe token format defined in RFC 7519. A JWT contains a structured payload of claims—statements about the client and authorization. Common standardized claims include:

• iss (Issuer): The authorization server that created the token.
• sub (Subject): The identifier of the user or client the token represents.
• aud (Audience): The intended recipient resource server(s).
• exp (Expiration Time): The token's expiry timestamp.
• scope: The granted permissions. These claims enable stateless validation by the resource server using a digital signature (JWS) or encryption (JWE).

Token validation by the resource server follows one of two primary patterns:

• Stateless Validation: Used with self-contained tokens like JWTs. The resource server validates the token's cryptographic signature and checks its claims (exp, aud, iss) locally without querying the authorization server. This offers high performance and scalability.
• Stateful (Introspection): Used with opaque reference tokens. The resource server must call the authorization server's token introspection endpoint (RFC 7662) to validate the token's active state and retrieve its metadata. This provides centralized revocation control but adds latency and a dependency on the authorization server.

Advanced security profiles, such as FAPI (Financial-grade API), move beyond simple bearer tokens to mitigate token replay and theft. They enforce token binding where the access token is cryptographically bound to a specific client or a TLS session. Techniques include:

• Demonstration of Proof-of-Possession (DPoP): The client signs a proof with a private key, binding the token to that key.
• Mutual TLS (mTLS) Client Certificate Binding: The token's cnf (confirmation) claim contains a hash of the client's TLS certificate, tying the token to that specific authenticated channel. These mechanisms ensure that even if a token is intercepted, it cannot be used by an unauthorized client.

An access token progresses through a managed lifecycle:

1. Issuance: Created by the authorization server after successful client authentication and user consent.
2. Usage: Presented to the resource server in the Authorization: Bearer <token> header.
3. Expiration: Automatically invalidated after its exp claim time passes.
4. Revocation: Can be proactively invalidated before expiry via a revocation endpoint (RFC 7009). This is critical for responding to security incidents (e.g., a stolen device) or user-initiated logout. Revocation is immediate for stateful tokens but requires token blacklisting or short expiry for stateless JWTs.

OAuth 2.0 is the industry-standard authorization framework that defines the protocols for issuing access tokens. It enables a client application to obtain limited access to a user's resources on an HTTP service without sharing the user's credentials. The framework specifies several grant types (flows) for different client types, such as the Authorization Code flow for web apps and the Client Credentials flow for machine-to-machine communication. It is the foundational protocol upon which access tokens are created and managed.

A JSON Web Token (JWT) is a compact, URL-safe token format (RFC 7519) commonly used as the structure for OAuth 2.0 access tokens and OpenID Connect ID tokens. A JWT encodes a set of claims as a JSON object, which is then signed using a JSON Web Signature (JWS) to ensure integrity. The three parts of a JWT (header, payload, signature) allow a resource server to validate the token's authenticity and expiration without a call to the authorization server, enabling stateless validation. Key claims include iss (issuer), exp (expiration), and scope.

A refresh token is a long-lived credential issued alongside an access token in certain OAuth 2.0 flows (like Authorization Code). Its sole purpose is to obtain a new access token when the current one expires, without requiring the user to re-authenticate. This improves user experience and security by limiting the exposure of the primary credentials. Refresh tokens must be stored securely by the client and are subject to strict revocation policies. They are not sent to resource servers and are only used in communication with the authorization server's token endpoint.

In OAuth 2.0, a scope is a mechanism that limits an application's access to a user's account or an API's capabilities. Scopes represent a specific permission or set of permissions (e.g., read:contacts, write:files) that the access token will grant. During authorization, the client requests a set of scopes, and the user consents to them. The issued access token is then bound to these scopes. The resource server must validate that the token presented contains a scope that permits the requested action, enforcing the principle of least privilege.

A bearer token is the most common type of access token in OAuth 2.0, defined in RFC 6750. It is called a 'bearer' token because possession alone is sufficient to grant access to the protected resource. The client presents the token in the HTTP Authorization header (e.g., Authorization: Bearer <token>). The resource server validates the token's signature and checks its validity period and scopes. This model requires strong transport security (HTTPS/TLS) to prevent token interception and mandates that tokens have short lifespans to mitigate the risk of theft.

Token Introspection (RFC 7662) is an OAuth 2.0 extension that allows a resource server to query the authorization server to determine the active state and meta-information of an access token. Instead of, or in addition to, validating a JWT locally, the resource server sends the token to a dedicated introspection endpoint. The authorization server responds with a JSON object indicating if the token is active, along with claims like client_id, username, and scope. This is crucial for immediate revocation enforcement and in scenarios where token validation logic is centralized.