Smash Security Threats Like Pro!
Transmit Security is serving up unbeatable protection – and custom pickleball paddles at RSA 2025. Book a meeting to grab yours and take your security game to the next level!
Transmit Security is serving up unbeatable protection – and custom pickleball paddles at RSA 2025. Book a meeting to grab yours and take your security game to the next level!
Glossary
An access token is a credential an application presents to an API to request authorized access. Its permissions and lifetime limit what the application can do.
In OAuth 2.0, an authorization server issues the token after approving an application’s request for access. The application can then call a protected application programming interface (API) without passing the customer’s password to that service. Access tokens also support applications acting on their own behalf, where no customer is signing in.
The application sends the token with a request to the resource server, the service hosting the protected API. That server validates the token and checks whether the requested operation is allowed. A valid token does not automatically grant access to every record the API holds.
For example, a budgeting app might receive permission to read a customer’s transactions. The bank must still ensure that requests are limited to the authorized accounts. Permission to read those transactions should not also permit the app to move money.
Scopes describe the granted permissions. An audience restriction limits which API should accept the token, while expiration bounds how long it remains usable.
These terms describe different properties. An access token has a purpose: authorizing access to a protected resource. A JSON Web Token (JWT) is one possible format. An opaque token instead exposes no claims the application can interpret; the API can obtain its status and authorization information through a server-side check such as token introspection.
A bearer token can be used by whoever possesses it, without separate proof that they hold a cryptographic key. Both JWT and opaque access tokens can use this model. Sender-constrained tokens require proof tied to the client, making a stolen token alone less useful.
A customer can complete strong authentication and still have an access token stolen from a compromised application or device. Replaying a bearer token can let an attacker use the access it carries until the API stops accepting it.
Short lifetimes reduce that exposure window. Applications should keep tokens out of logs and URLs, and send them over HTTPS. APIs must apply the validation rules for the token type, including the intended issuer and audience where applicable, then enforce authorization for the requested resource. Checking a JWT signature alone is insufficient.
When access expires, an application may use a refresh token to request a replacement. Whether that option is available depends on the authorization flow and the server’s policy.
Is an access token always a JWT?
No. OAuth does not require one access-token format. A token can be a JWT or an opaque value, with validation handled accordingly.
What is the difference between an access token and an ID token?
An access token is intended for a protected API. An ID token tells an OpenID Connect client about the user’s authentication and identity.
Does an access token grant access to every customer account?
No. The API must enforce the granted permissions and check access to the specific resource requested. Possessing a valid token does not bypass those checks.
Related: OAuth 2.0 · Token-Based Authorization (JWT) · API Security · Authorization · Principle of Least Privilege · Account Takeover (ATO)
