An access token is a credential that authorises a client or user to call a service or API for a limited time and with specific permissions. Attackers steal tokens to bypass passwords and multi-factor checks, so defenders should limit token scope and lifetime, protect storage, and revoke tokens after compromise.
What an access token does
An access token is a time-limited credential that grants a client or user permission to call a service or API. Its security value comes from what it can reach, so scope, audience and expiry matter as much as the token itself.
Because tokens can be replayed by whoever holds them, they often function as a portable proof of authorization. That makes them useful for single sign-on, delegated access and service-to-service calls, but also attractive to attackers who want to bypass interactive login controls.
Why access tokens are dangerous when stolen
Token theft is dangerous because a valid token can let an attacker act as the original holder without needing the password again. In practice, that means stolen tokens can bypass MFA, session controls and other front-door checks until the token expires or is revoked.
Token misuse becomes especially severe when tokens are over-scoped, long-lived or accepted across many services. A stolen token can then be used for data access, privilege escalation or lateral movement, depending on what the token is allowed to do.
Incidents such as Salesloft OAuth token breach and Sourcegraph breach 2023 show how a token can become a direct path into API access, admin capability or exposed data when it is left accessible or reused too widely.
How organisations reduce exposure
The first control is to know where tokens exist: in apps, CI/CD systems, browsers, developer tooling, integrations and vendor connections. Inventory matters because organisations often lose track of where tokens are issued, stored, forwarded or cached.
Good exposure management also means making tokens as narrow as possible. Limit audience, permissions and lifetime, and prefer short-lived or sender-constrained designs where the token cannot be replayed easily outside its intended context.
For implementation guidance, the OAuth 2.0 framework in RFC 6749: The OAuth 2.0 Authorization Framework establishes the basic model for delegated access, while RFC 9700: Best Current Practice for OAuth 2.0 Security and RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) address modern token protection and replay resistance.
Detection, response and post-compromise review
Token abuse is often hard to spot because the attacker is using a legitimate credential path. Detection therefore needs to focus on unusual token use, impossible geography, unexpected API calls, new user-agent patterns, abnormal consent events and access after a token should have expired.
After suspected compromise, organisations should assume that any system touched by the token may also be exposed. Review downstream activity, connected sessions and any permissions that the token could reach, then revoke or reissue credentials where the token was embedded or stored.
Internet Archive breach 2024 and Guide to the Secret Sprawl Challenge both reinforce a practical lesson: if a token was exposed, rotation alone is not enough unless teams also review persistence, reuse and any paths that allowed the same credential to be replayed later.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | Access tokens underpin API authentication and replay risk. |
| Recommendation — Validate token handling so stolen or replayed tokens do not bypass API authentication. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Tokens are authenticator material that must be issued, protected and revoked safely. |
| AC-6 — Least Privilege | Token scope determines the authority a stolen token can exercise. | |
| Recommendation — Manage token lifecycle to limit exposure, enforce expiry and revoke compromised credentials. Restrict token permissions to the minimum access needed for the task. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Tokens are access mechanisms that require inventory, restriction and revocation. |
| Recommendation — Inventory and revoke token-based access paths when they are no longer needed or are compromised. | ||
| OWASP ASVS | V7 — Session Management | Bearer tokens often function as session credentials and must resist theft and replay. |
| Recommendation — Harden token lifecycle and session handling to reduce replay and fixation risk. | ||
Practitioner Guidance
Why practitioners should care: Access tokens are not just plumbing for APIs, they are live authorization artefacts. Treat them like sensitive credentials, because whoever controls the token can usually inherit the authority it carries.
What to watch for: The biggest warning signs are broad scopes, long validity periods, token reuse across environments and storage in places that are easy to copy, such as logs, source code, chat, build systems or browser sessions.
Practitioner takeaway: If a token is exposed, respond as though access has already been granted and validate the full blast radius, not only the token string itself.