When you sign in to an online service, your password or another authentication method is usually checked only at the beginning of the session. After that, the service often relies on access tokens so that you do not need to enter your password for every request.
This design makes modern web applications, mobile apps, cloud services and single sign-on practical. But it also means that the token itself becomes a valuable credential.
What is an access token?
An access token is a credential representing permission to use particular resources or perform particular actions. In OAuth-based systems, an authorisation server issues a token after the required authentication and authorisation steps have succeeded.
The application then presents that token when requesting access to an API or other protected resource.
Authentication and authorisation are different
Authentication answers “Who are you?” Passwords, passkeys, security keys and other factors can help answer that question.
Authorisation answers “What are you allowed to do?” Access tokens commonly represent those permissions after authentication has already happened.
How the process works
- You sign in. The service asks for the required authentication evidence.
- Your identity is verified. The identity system checks the credentials and any additional factors.
- A token is issued. The token represents authorised access for a particular scope, audience and period.
- The token is presented. Your browser, app or device sends it when accessing protected resources.
- The receiving application validates it. Depending on the token type, the service can check properties such as issuer, signature, audience and expiry before granting access.
Why single sign-on uses tokens
Single sign-on lets one successful authentication provide access to several authorised applications without asking you to re-enter your password each time.
The applications do not need to receive your password. Instead, they rely on tokens or assertions issued by a trusted identity system.
Why stolen tokens can bypass password entry
Suppose a legitimate user signs in and receives a valid token. If an attacker later obtains that usable token, the attacker may try to present it directly to the application.
The attacker has not cracked the password. They are reusing a credential that was issued after authentication.
If the application accepts the token and no additional control blocks its reuse, access may be granted without another password prompt.
Bearer tokens need special protection
A bearer token works much like a ticket: possession of the valid token can be sufficient to exercise the permissions associated with it.
This is why bearer tokens must be protected in storage and in transit and why systems should minimise the damage a stolen token can cause.
Common token risks
- Token theft: a valid token is exposed or stolen from a browser, device, application or storage location.
- Token forgery: an attacker tries to create a token that appears legitimate.
- Overly long lifetime: a stolen token remains useful for too long.
- Weak signing-key protection: compromised keys can undermine trust in issued tokens.
- Poor revocation: compromised tokens cannot be invalidated quickly.
- Overly broad privileges: a token grants more access than the application actually needs.
How services reduce the risk
Protect signing keys
Cryptographic keys used to sign or validate tokens must be securely generated, stored, rotated and managed.
Use appropriate token lifetimes
Shorter lifetimes can reduce the amount of time a stolen access token remains useful. The correct lifetime depends on the application and risk level.
Validate tokens carefully
Applications should validate the properties required by their protocol and architecture, which can include the issuer, intended audience, signature and expiry time.
Limit privileges
A token should normally carry only the permissions needed for its task. This follows the principle of least privilege.
Support revocation and monitoring
Systems should be able to invalidate compromised sessions or tokens where the protocol permits and should monitor for suspicious use.
Protect tokens in transit and storage
Tokens should travel over secure connections and should not be exposed unnecessarily in logs, URLs, screenshots or insecure local storage.
Why a strong password is not enough
A strong password is still important, but it protects the authentication step. It cannot by itself protect a valid token that has already been stolen after authentication.
Good identity security therefore protects the whole lifecycle: authentication, token issuance, storage, validation, expiry, revocation and monitoring.
Does multi-factor authentication stop token theft?
Multi-factor authentication can make account takeover much harder, especially when an attacker has only a password. But it does not automatically make every already-issued token unusable.
Some systems add extra protections such as device binding, re-authentication for sensitive actions or risk-based session checks.
Common misconceptions
“Access tokens are just encrypted passwords.” No. They are separate credentials representing authorised access.
“If my password is strong, stolen tokens cannot matter.” A valid token may be accepted after the password step has already been completed.
“Longer-lived tokens are always better because they are more convenient.” Longer lifetimes can increase exposure if a token is compromised.
Key takeaways
- Access tokens represent authorised access after authentication.
- Single sign-on can use tokens so users do not need to re-enter passwords for every authorised application.
- A stolen valid token may allow access without the attacker knowing the user's password.
- Strong validation, limited privileges, appropriate lifetimes, secure storage and revocation reduce risk.
- Token security is part of the whole identity lifecycle, not a replacement for strong authentication.
Frequently asked questions
Is an access token the same as a password?
No. A password is generally used to prove identity. An access token usually represents permissions that were granted after authentication.
Can a token be used forever?
Good systems normally give tokens defined lifetimes. The exact lifetime depends on the application and security requirements.
Does changing a password revoke every token?
Not necessarily. Services differ. If compromise is suspected, use the service's session-management and security controls as well as changing credentials.
Is OAuth unsafe?
No. OAuth is a widely used authorisation framework. Security depends on correct implementation and appropriate protection of tokens and keys.
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 — Bearer Token Usage.
- IETF RFC 9700 — Best Current Practice for OAuth 2.0 Security.
