Bearer Token

The fundamental principle of a bearer token is that possession equals authorization. Any client that presents a valid, unexpired bearer token is granted access to the associated resources, without the resource server needing to perform additional cryptographic validation beyond checking the token's signature and validity. This model is simple but carries significant risk if the token is intercepted or leaked.

• Key Implication: The token itself is the secret. There is no additional proof-of-possession required from the client.
• Security Consequence: Transmission must always use TLS (HTTPS) to prevent token interception. Tokens must be stored securely on the client side.

A properly implemented bearer token, such as a signed JSON Web Token (JWT), allows the resource server (API) to validate it without querying the authorization server for every request. The server can cryptographically verify the token's signature and inspect its embedded claims (like exp for expiration and scope for permissions).

• Performance Benefit: Eliminates a network call to the authorization server for introspection on each API request, reducing latency.
• Architectural Decoupling: Enables scalable, distributed systems where APIs can operate independently of the central auth server, relying on a shared trust anchor (like a public JWKS endpoint).

Bearer tokens are not master keys; they are issued for specific purposes. The scope claim defines the permissions granted (e.g., read:contacts, write:invoices). The aud (audience) claim specifies the intended recipient resource server(s). The resource server must validate both to enforce the principle of least privilege.

• Scope Enforcement: An API receiving a token with scope read must reject a POST request.
• Audience Validation: A token issued for https://api.payments.com must be rejected by https://api.analytics.com.

Bearer tokens are designed to be short-lived (e.g., expiring in minutes or hours) to limit the window of misuse if compromised. A separate, long-lived refresh token is used to obtain new access tokens without requiring user re-authentication. This pattern balances security and user experience.

• Standard Flow: The client uses a refresh token (securely stored) at the authorization server's token endpoint to get a new access/refresh token pair.
• Security Benefit: Compromised access tokens are only useful until they expire. Refresh tokens require stricter storage and can be revoked centrally.

Bearer tokens are transmitted from client to server using a standardized HTTP header, as defined in RFC 6750. The primary method is the Authorization header with the Bearer scheme.

Example Header: Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

• Alternative Methods: RFC 6750 also defines transmission via form-encoded body parameters or URI query parameters, but these are less secure and not recommended for primary use.
• Universal Support: This header-based method is universally understood by API gateways, proxies, and server frameworks, enabling seamless integration.

The possession-based model introduces specific threats that must be mitigated:

• Token Theft/Replay: If intercepted, the token can be replayed by an attacker. Mitigations: Enforce TLS everywhere, use short expiry times, and employ token binding or DPoP (Demonstrating Proof-of-Possession) where higher assurance is required.
• Insufficient Scope Validation: APIs must strictly validate the scope claim. Mitigation: Implement centralized authorization logic that checks token scopes against the requested action.
• Storage on Client: Tokens in browser localStorage are vulnerable to XSS. Tokens in mobile apps can be extracted. Mitigation: Use secure, HTTP-only cookies for web apps when possible, and platform-specific secure storage (Keychain, Keystore) for mobile.

An access token is the core OAuth 2.0 credential used to access protected resources. It is issued by an authorization server to a client after successful authentication and authorization. The token contains claims about the grant (e.g., scopes, client ID, user ID, expiration). A bearer token is one specific type of access token, defined by its possession-based security model where the presenter is assumed to be the authorized party.

• Bearer tokens are a subset of access tokens.
• Other token types may require proof-of-possession (PoP) beyond mere presentation.
• Tokens can be opaque (a random string requiring introspection) or self-contained like a JWT.

A JSON Web Token (JWT) is a compact, URL-safe token format (RFC 7519) commonly used as a self-contained access or ID token. A JWT consists of three Base64Url-encoded parts separated by dots: a header, a payload (claims), and a signature. When a bearer token is formatted as a JWT, the resource server can validate it locally by verifying its cryptographic signature and checking standard claims like expiration (exp) and audience (aud), without a call to the authorization server.

• Structure: HEADER.PAYLOAD.SIGNATURE
• Common Algorithms: RS256, ES256, HS256
• Key Benefit: Enables stateless validation, reducing latency and load on the auth server.

OAuth 2.0 (RFC 6749) is the authorization framework that defines the bearer token concept. It is a protocol that allows a client application to obtain limited access to a user's resources on an HTTP service without exposing the user's credentials. The framework specifies several grant flows (e.g., Authorization Code, Client Credentials) for obtaining tokens. The bearer token usage is detailed in a separate RFC (6750).

• Core Roles: Resource Owner, Client, Authorization Server, Resource Server.
• Bearer Token Specification: RFC 6750.
• Primary Purpose: Delegated authorization, not authentication (though often used with OpenID Connect for auth).

A scope is an OAuth 2.0 mechanism that limits an application's access to a user's account. Scopes are strings (e.g., read:contacts, write:files) that represent specific permissions. During the authorization request, the client requests certain scopes. The issued bearer token is then bound to these scopes. The resource server must validate that the token presented contains a scope granting permission for the requested action.

• Example: A token with scope api:read cannot be used for a POST request.
• Implementation: Scopes are typically included as a claim within the access token.
• Principle of Least Privilege: Clients should request only the minimum scopes necessary for functionality.

Token introspection (RFC 7662) is a protocol that allows a resource server to query the authorization server to determine the active state and meta-information of an access token. This is critical for validating opaque bearer tokens, which are random strings that cannot be decoded locally. The introspection endpoint returns a JSON response indicating if the token is active and providing its associated claims (client_id, username, scopes, exp).

• Use Case: Essential for centralized token validation and immediate revocation enforcement.
• Performance Trade-off: Adds a network call for every API request, increasing latency.
• Standard Endpoint: POST /oauth/introspect

PKCE (RFC 7636) is an extension to the OAuth 2.0 Authorization Code flow designed to secure public clients (like mobile and single-page apps) against authorization code interception attacks. While PKCE secures the initial code exchange, the resulting bearer token remains vulnerable if leaked. Therefore, PKCE is often combined with short-lived bearer tokens and secure storage practices.

• Mechanism: Client creates a cryptographically random code_verifier and sends a derived code_challenge during the authorization request.
• Mitigates: Authorization code interception ("man-in-the-middle").
• Does Not Mitigate: Bearer token theft from client storage. It secures the flow, not the token itself.