Category: Tokens & Sessions

Access Token

Simply put

An access token is a string of data that an application presents to a protected resource, such as an API, to prove it has been granted permission to access that resource. Rather than repeatedly sending a user's login credentials, the application sends this token with each request. The token typically carries information about what the application is allowed to do and for how long.

Formal definition

In OAuth 2.0, an access token is a credential used by a client to make authorized requests to a resource server on behalf of a principal (per oauth.net). It is an authorization artifact, not proof of user authentication; conflating it with an ID token or with authentication is a common error. The OAuth 2.0 framework does not mandate a particular token format, so access tokens may be opaque strings whose meaning is resolvable only by the issuer or introspection endpoint, or self-contained tokens such as JWTs whose claims (for example scopes, audience, and expiry) can be validated by the resource server. Depending on deployment and profile, tokens are typically signed to ensure integrity, though signing alone does not provide confidentiality unless the token is also encrypted. Access tokens are generally short-lived and, where supported, renewed via a refresh token; exact lifetimes, formats, and validation mechanics vary by vendor and configuration.

Why it matters

Access tokens are the workhorse credential of modern API-driven architectures. By allowing an application to present a token instead of a user's login credentials on every request, they reduce how often raw credentials are transmitted and handled, and they let resource servers make authorization decisions without re-authenticating the user each time. This design underpins delegated access patterns across OAuth 2.0 deployments, where a client acts on behalf of a principal against a resource server.

Because an access token is a bearer artifact in most common deployments, whoever possesses it can typically use it until it expires or is revoked. That makes token handling, transport security, scoping, and lifetime management central security concerns. Access tokens are generally kept short-lived precisely to limit the window of misuse if one is leaked, with renewal handled through refresh tokens where supported. Treating a signed token as if it were also confidential is a common mistake: signing protects integrity, not secrecy, so a token that is not encrypted may expose its claims to anyone who intercepts it.

A frequent and consequential error is conflating an access token with authentication. An access token is an authorization artifact that expresses what a client may do; it is not proof that a user was authenticated, which is the role of an ID token in OpenID Connect. Using an access token as evidence of user identity, or validating it as though it carried authentication guarantees, can lead to broken authorization logic and access decisions that do not hold up under scrutiny.

Who it's relevant to

IAM Engineers and API Developers

Engineers integrating clients with resource servers must choose between opaque and self-contained token formats, implement correct validation (introspection for opaque tokens, or signature, audience, scope, and expiry checks for JWTs), and handle token lifetimes and refresh flows. They must also avoid treating access tokens as authentication evidence, reserving that role for ID tokens in OpenID Connect.

Security Architects

Architects designing delegated authorization define token lifetimes, scoping, and transport protections, and decide when encryption is needed in addition to signing to protect claim confidentiality. They weigh the trade-offs of bearer tokens and the operational implications of short-lived tokens paired with refresh tokens across their deployment and chosen profile.

Compliance and Audit Teams

Auditors reviewing access enforcement need to confirm that tokens carry appropriately scoped permissions, that lifetimes limit exposure, and that authorization decisions are based on token scopes and audience rather than misused as proof of user authentication. Because behavior varies by vendor and configuration, they should verify actual deployment settings rather than assume defaults.

Inside Access Token

Authorization grant context

An access token represents a set of authorization decisions delegated to a client, typically encoding the scopes and permissions the client may exercise against a resource server. In OAuth 2.0, it is the credential the client presents to access protected resources, not a proof of user authentication.

Scopes

The access token conveys the granted scopes that bound what actions or resources the bearer may access. Scopes represent the delegated authorization and are typically defined by the authorization server and resource server contract.

Token format (self-contained vs. opaque)

An access token may be self-contained (for example, a JWT whose claims can be validated by the resource server) or opaque (a reference string that the resource server validates by introspection at the authorization server). The format used depends on deployment and configuration.

Claims (when self-contained)

When formatted as a JWT, an access token typically carries claims such as issuer, audience, subject, expiration, and issued-at, plus scope or permission claims. The exact claim set varies by authorization server and profile.

Signature and integrity

Self-contained access tokens are typically signed so a resource server can verify integrity and issuer authenticity. Signing is not the same as encryption; unless additionally encrypted, a signed token's payload may be readable by anyone who obtains it.

Lifetime and expiration

Access tokens are typically short-lived and carry an expiration, after which they must be refreshed or reissued (often using a refresh token). The exact lifetime is set by the authorization server configuration.

Common questions

Answers to the questions practitioners most commonly ask about Access Token.

Does an access token authenticate the user to the resource server?

No. An access token is an authorization credential, not an authentication assertion about the end user. In the OAuth 2.0 model, it represents a delegated grant that authorizes a client to access protected resources on a resource server, typically within a specific scope. It is not intended to convey verified user identity to the client; that role belongs to the ID token in OpenID Connect. Treating an access token as proof that a user authenticated conflates authorization with authentication and can lead to insecure client behavior.

If an access token is signed, does that mean its contents are protected from being read?

No. Signing and encryption are distinct protections. A signed token, such as a JWT signed with a JWS structure, provides integrity and lets a verifier confirm the token was issued by a trusted party and not tampered with. It does not conceal the contents; the payload of a signed-but-unencrypted JWT can typically be decoded and read by anyone who holds it. To keep claims confidential in transit or at rest, the token must additionally be encrypted (for example as a JWE), which is a separate mechanism from signing.

How should a resource server validate an incoming access token?

It depends on the token format. For a self-contained token such as a signed JWT, the resource server typically validates the signature against the issuer's published keys, then checks claims such as issuer, audience, expiration, and any required scopes, depending on configuration. For an opaque token, the resource server generally cannot inspect the token locally and instead calls the authorization server's introspection endpoint to determine validity and associated metadata. The correct approach is dictated by the token type your authorization server issues.

What is a reasonable lifetime for an access token?

Access tokens are typically short-lived to limit the window of misuse if one is leaked, with refresh tokens used to obtain new access tokens without re-prompting the user. Exact durations vary by deployment, risk profile, and vendor defaults, so there is no single correct value. Shorter lifetimes reduce exposure but increase token-refresh traffic and dependence on refresh token handling. Choose a lifetime based on your threat model, the sensitivity of the resources, and whether revocation or introspection is available.

Where should a client store an access token?

Storage choices depend on the client type and its environment, and each option carries trade-offs. The general principle is to minimize exposure: avoid placing tokens where they can be read by untrusted code, keep them out of URLs and logs, and scope their reach to what the client needs. Because appropriate handling varies significantly between confidential server-side clients and public browser or mobile clients, follow the guidance for your specific client profile rather than a universal rule. Detailed platform-specific storage guidance is out of scope for this entry.

What should happen when an access token expires or needs to be revoked?

On expiration, a client typically uses a refresh token, where issued, to obtain a new access token without requiring the user to re-authenticate, depending on configuration. Revocation is more nuanced: self-contained tokens such as JWTs are generally hard to revoke before expiry unless the resource server performs introspection or checks a revocation mechanism, which is why short lifetimes are common. Opaque tokens can typically be invalidated at the authorization server so that subsequent introspection fails. The available revocation behavior depends on the token type and the authorization server's capabilities.

Common misconceptions

An access token authenticates the user to the client application.

An access token is an authorization credential in OAuth 2.0 used to access protected resources; it does not authenticate the user to the client. Authentication of the user is conveyed by an ID token in OpenID Connect, which is the authentication layer built on top of OAuth 2.0. Access tokens and ID tokens serve distinct purposes and should not be interchanged.

Because an access token is signed, its contents are confidential.

Signing provides integrity and issuer authenticity, not confidentiality. Unless the token is additionally encrypted, the payload of a self-contained token may be readable by any party that obtains it. Treat access tokens as sensitive credentials regardless of signing.

A resource server can always validate an access token by inspecting the token itself.

This only holds for self-contained tokens such as JWTs. Opaque access tokens carry no verifiable claims and are typically validated by introspection at the authorization server. The validation approach depends on the token format and deployment.

Best practices

Keep access token lifetimes short and rely on refresh tokens for continued access where appropriate, reducing the exposure window if a token is compromised.

Use the access token only for authorization at resource servers; use an OpenID Connect ID token, not the access token, when the client needs to establish who the user is.

Validate tokens correctly for their format: verify signature, issuer, audience, and expiration for self-contained JWTs, and use introspection at the authorization server for opaque tokens.

Request and grant the minimum scopes necessary, aligning the token's authorization with the principle of least privilege.

Transmit and store access tokens as sensitive credentials, protecting them in transit and at rest, and consider encryption where payload confidentiality is required in addition to signing.

Confirm audience and issuer values at the resource server so a token issued for one audience cannot be replayed against an unintended resource, depending on your deployment profile.