Access Tokens Explained: How Token Theft Can Bypass Your Password

Entering a password is often only the beginning of an online session. After a successful sign-in, websites, mobile apps and cloud services commonly rely on tokens so that you do not have to send your password with every request.

That design is useful and usually safer than repeatedly sharing a password. But it creates another security question: what happens if an attacker steals a valid access token?

In September 2026, the US National Institute of Standards and Technology (NIST), working with the Cybersecurity and Infrastructure Security Agency (CISA), finalised NIST IR 8587, guidance focused specifically on protecting identity and access tokens from forgery, theft and misuse. The underlying lesson is useful to everyone who uses modern web services: protecting the password is essential, but it is not the whole authentication story.

What is an access token?

An access token is a credential that represents permission to access particular resources or perform particular actions. In OAuth-based systems, an authorisation server issues the token after the required authentication and authorisation steps have taken place.

The application can then present that token to a resource server, such as an API, instead of sending the user's password.

A token may represent limits such as:

• which service may receive it;
• which actions are permitted;
• which account or application it represents;
• when it expires;
• other conditions imposed by the system.

The exact structure varies. Some tokens are opaque random values whose meaning is stored on a server. Others contain signed information that a receiving service can verify.

Authentication and authorisation are not the same thing

This distinction makes token security easier to understand.

Authentication answers a question such as: “Who are you?” A password, passkey, security key or another factor can participate in that process.

Authorisation answers: “What are you allowed to do?” An access token can carry or represent that permission after authentication has already happened.

For example, you might sign in to a cloud service using a passkey. After the service verifies you, it can issue tokens that allow your browser or app to read your files, send requests or access other authorised resources without asking for the passkey again on every click.

What is a bearer token?

OAuth's bearer-token specification uses a particularly important model. A bearer token works much like a ticket: a party presenting a valid token can use the associated permissions without separately proving possession of another cryptographic key.

That convenience is why bearer tokens must be protected carefully. The Internet Engineering Task Force's bearer-token specification warns that any party possessing such a token can use it to obtain the resources associated with it.

How can token theft bypass a password?

Imagine that Alice signs in normally. Her password or passkey is checked, and the service issues a valid token to her browser. The token says, in effect, “this session may access Alice's authorised resources until these conditions expire.”

If an attacker somehow obtains that usable bearer token, the attacker may attempt to present the token directly to the service. The service may see a valid token and accept the authorised request without asking the attacker to enter Alice's password again.

The attacker has not mathematically defeated the password. Instead, the attacker has stolen a credential that was issued after the password check.

This is why changing a password does not always instantly terminate every active session unless the service also revokes or invalidates relevant tokens and sessions.

A simple analogy: the hotel key card

Suppose a hotel receptionist checks your identity before giving you a room key card. Your identification is analogous to authentication. The key card is analogous to a token: it gives its holder permission to open particular doors for a limited period.

If somebody steals the working key card, they do not need to impersonate you at reception. They may simply try the card at the door.

The analogy is not technically perfect, but it demonstrates why a credential issued after authentication must itself be protected.

Where are tokens used?

Tokens appear throughout modern computing, including:

• single sign-on systems;
• OAuth and OpenID Connect deployments;
• mobile and web applications;
• cloud platforms;
• application programming interfaces (APIs);
• federated identity systems;
• machine-to-machine services.

You may use token-based systems every day without seeing the tokens themselves.

How can tokens be stolen or misused?

There is no single token-theft technique. Risks depend on the architecture. Security failures can involve malicious software, insecure storage, accidental logging, compromised applications, vulnerable browser environments, improperly protected network traffic, token leakage into URLs or other data, stolen signing keys, or weaknesses in the surrounding identity infrastructure.

This does not mean tokens are inherently unsafe. Tokens are fundamental to secure modern systems. The lesson is that they are credentials and should be treated accordingly.

Why HTTPS matters

OAuth security guidance requires protection of bearer tokens in transit. Transport Layer Security (TLS), used by HTTPS, helps prevent people who can observe network traffic from simply reading credentials travelling between a client and a legitimate service.

HTTPS alone cannot stop every form of token theft—for example, malware running on an already compromised device may operate above the encrypted network layer—but sending sensitive bearer tokens over unprotected connections creates unnecessary exposure.

Why short token lifetimes help

A stolen token that remains valid indefinitely creates a larger window for misuse. Systems can reduce that window by giving access tokens limited lifetimes.

Short-lived access tokens often work alongside mechanisms that allow legitimate applications to obtain new tokens without repeatedly asking users to sign in. Those renewal mechanisms must also be protected because a long-lived refresh credential can itself become valuable to an attacker.

Scopes and least privilege

Good token design also limits what a token can do. OAuth calls these permissions scopes.

An application that only needs permission to read a calendar should not automatically receive permission to delete cloud files or administer an entire account. If a narrowly scoped token is stolen, the potential damage can be smaller than if the token grants unrestricted access.

This follows the broader security principle of least privilege: give a user, application or credential only the permissions necessary for its task.

Audience restriction

A token intended for one service should not automatically work at every other service. Systems can restrict the token's audience so that a receiving service verifies that the token was actually meant for it.

This matters in complex cloud environments where many APIs and services communicate with one another. Without appropriate restrictions, a credential leaked from one context might be reusable somewhere it was never intended to operate.

What NIST's 2026 guidance adds

NIST IR 8587 focuses on the security of identity tokens, access tokens and assertions across their lifecycle. NIST describes threats including forgery, theft and misuse and provides implementation recommendations for federal agencies and other organisations that use token-based identity systems.

The guidance emphasises that token security is not merely a developer detail. Organisations need controls spanning token issuance, validation, storage, signing-key protection, lifecycle management, monitoring and incident response.

The broader lesson is that identity systems form chains. Strong authentication at the beginning of that chain cannot compensate for every weakness later in the token lifecycle.

Does multi-factor authentication stop token theft?

Multi-factor authentication can substantially improve account security, particularly against password theft, but it does not make every already-issued token unusable.

If an attacker steals a valid session or bearer token after the legitimate user has completed authentication, the service may not ask for those factors again for every request.

Modern systems can add further protections, such as requiring fresh authentication for sensitive actions, detecting suspicious sessions, binding credentials more closely to particular clients, and rapidly revoking compromised tokens.

What ordinary users can do

Most people never manually manage OAuth access tokens, but several habits can reduce exposure:

• keep browsers, operating systems and applications updated;
• avoid installing untrusted browser extensions or software;
• use phishing-resistant authentication such as passkeys or security keys where available;
• review active sessions and connected applications when a service provides those controls;
• sign out of unfamiliar sessions;
• treat unexpected account activity as a reason to review both passwords and sessions;
• avoid copying sensitive authentication information into chats, screenshots, support tickets or public posts.

What developers and organisations should consider

Token security is primarily an architectural responsibility. Depending on the system, useful controls can include:

• using TLS correctly;
• limiting token lifetime;
• restricting scopes and audiences;
• protecting tokens at rest;
• keeping tokens out of insecure logs and URLs;
• protecting cryptographic signing keys;
• validating issuer, audience, signature and expiry information where applicable;
• supporting revocation and session termination;
• monitoring suspicious token use;
• following current OAuth and identity-security standards rather than inventing proprietary authentication schemes.

Common misconceptions

“If my password is strong, nobody can access my account without it.” A strong password is valuable, but other credentials such as valid session or access tokens may also grant access.

“Tokens are just encrypted passwords.” Usually not. Access tokens represent authorisation and need not contain a password at all.

“Two-factor authentication makes stolen tokens harmless.” MFA protects important parts of the authentication process, but a valid token stolen after authentication may still be useful unless additional controls prevent its reuse.

“Longer-lived tokens are always better because users sign in less.” Convenience and security must be balanced. Longer validity can increase the period during which a stolen credential remains useful.

Key takeaways

• An access token is a credential representing permission to access protected resources.
• A bearer token can generally be used by whoever possesses it, so it must be protected from disclosure.
• Token theft can appear to “bypass” a password because the token was issued after authentication and may be accepted without another password check.
• HTTPS, limited lifetimes, narrow scopes, audience restrictions, secure storage and good key management can reduce token-related risk.
• MFA remains important, but token and session security must be protected as part of the same identity system.
• NIST's 2026 guidance highlights the need to secure tokens throughout their complete lifecycle.

Frequently asked questions

Is an access token the same as a password?

No. A password is typically a secret used to authenticate a user. An access token normally represents authorisation that has already been granted to a client or session.

Can somebody use a stolen access token without knowing my password?

For a usable bearer token, potentially yes. That is why bearer tokens are treated as sensitive credentials. Whether reuse succeeds depends on the token, its validity, its permissions and the security controls implemented by the service.

Does changing my password revoke stolen tokens?

It depends on the service. Some systems revoke sessions or tokens when a password changes; others have different lifecycle rules. If compromise is suspected, use the service's session-management and account-security controls as well as changing credentials.

Are OAuth and access tokens unsafe?

No. OAuth is a widely used authorisation framework. The security outcome depends on correct implementation, appropriate token protection and adherence to current standards and guidance.

What is the safest token?

There is no universal token format that is safest for every architecture. Security depends on the threat model, token type, transport, storage, validation, lifetime, permissions, key management and surrounding system.

Authoritative references

• NIST — IR 8587: Protecting Tokens and Assertions from Forgery, Theft, and Misuse, finalised September 2026.
• IETF — RFC 6749: The OAuth 2.0 Authorization Framework.
• IETF — RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage.
• IETF — RFC 9700: Best Current Practice for OAuth 2.0 Security.