Introduction
OAuth and OpenID Connect (OIDC) are often introduced together, and for good reason: they are designed to work in tandem. But for many developers, that pairing creates confusion rather than clarity. This is especially true once multiple token types enter the picture. Why are there two different token types? Who receives each one? And where, exactly, are they supposed to be used?
This confusion often stems from an incomplete understanding of how OAuth and OIDC define the life cycles of access tokens and ID tokens.
This article focuses on clarifying how access tokens and ID tokens move through a system. Rather than walking through protocol mechanics or grant types, it explains how access tokens and ID tokens are used in practice — where they originate, where they travel, and where they stop. The goal is to make it easier to understand real systems based on OAuth and OIDC without turning the discussion into a standards deep dive.
The Purpose of Access Tokens and ID Tokens
One useful way to understand access tokens and ID tokens is to focus on their purpose rather than their structure.
An access token exists to enable access to protected resources. It is issued by an authorization server and is intended to be presented to APIs. When an API receives an access token, it validates the token and uses the information inside it — such as scopes or other claims — to decide whether the request should be allowed. Access tokens are about authorization: what the caller is permitted to do.
An ID token, by contrast, exists to represent an authenticated user to a client application. It is only issued when OIDC is involved and is defined to be consumed by the client itself, not by APIs for authorization decisions. An ID token allows the client to establish who the user is, confirm that authentication has occurred, and populate identity-related information used by the client application.
Both tokens are often JSON Web Tokens (JWTs) with similar structures, but they serve different audiences and answer different questions about a request. Access tokens are for APIs. ID tokens are for clients. Keeping that distinction clear is essential for understanding how access tokens and ID tokens are intended to be used within OAuth and OIDC.
How Access Tokens and ID Tokens Are Handled
Access tokens typically follow a straightforward path. After the authorization server issues an access token to a client, the client stores it locally (for example, in memory or another client-managed storage location) and presents it when calling an API.
Each time the API receives a request with an access token, it validates the token by checking the issuer (iss), audience (aud), and expiration (exp) claims, along with the signature — and then makes an authorization decision based on the claims in the token. The API does not authenticate the user itself; rather, it trusts the authorization server and enforces access based on the token it receives.
ID tokens follow a much shorter path than access tokens. The authorization server issues an ID token to the client, and that's where the intended journey ends. The client uses the ID token to establish the user's identity within the application, and the token is not intended to be used by APIs as an authorization credential. APIs generally cannot make meaningful authorization decisions based on ID tokens and sending them to APIs blurs responsibilities that OAuth and OIDC are designed to keep separate.
Access tokens move between clients and APIs. ID tokens are intended to remain with the client. Each token is designed to go only as far as it needs to within this model.
In applications based on OAuth and OIDC, a client may receive both an access token and an ID token as part of the same authorization interaction. This commonly occurs when the client needs user identity information for its own usage while also obtaining an access token to call protected APIs. Although the tokens are issued together, they still serve the same distinct purposes and follow the same paths already outlined.
Requests, Token Lifetimes, and Token Reuse
What happens when requests continue beyond the initial authentication interaction? With subsequent API calls, the client presents only the access token. The API evaluates that token on each request and treats the request as authenticated and authorized based on the token's validity and claims.
From the API's perspective, the access token defines the security context for the call — who is calling, what they are allowed to do, and whether the request should be accepted.
Token lifetimes play an important role here. Access tokens are intended to be short-lived, which limits the impact of token leakage and ensures that authorization decisions are regularly re-evaluated. Unlike access tokens, ID tokens are often configured with longer lifetimes because an ID token's expiration affects only the client's understanding of user identity, not the more sensitive act of API authorization.
Refresh tokens allow a client to obtain new access tokens without repeating the full authentication cycle. Importantly, this refresh process happens between the client and the authorization server. APIs are not involved in this process, and they continue to care only about whether the access token presented on each request is valid at that moment.
Common Misunderstandings About Token Usage and Flow
Even with a clear model of how access tokens and ID tokens are intended to move through a system, certain misunderstandings show up repeatedly in systems based on OAuth and OIDC.
- ID tokens should not be used to call APIs: One mistake that appears regularly is using an ID token to call an API. Because both access tokens and ID tokens are often JWTs containing structured claims, ID tokens can be mistaken as being intended for API authorization.
- APIs do not issue access tokens: A common assumption is that APIs generate or issue access tokens as part of handling requests. In OAuth and OIDC, token issuance is the responsibility of the authorization server. APIs remain downstream consumers of tokens, validating and enforcing them, but not creating them. Confusing these roles blurs the intended flow and weakens separation of concerns.
- Refresh tokens do not participate in API requests: Some implementations incorrectly treat refresh tokens as credentials that APIs should receive or act upon, for example, by sending them along with API calls. This can happen when developers send refresh tokens to an API so the API itself can request new access tokens on the client's behalf. In practice, refresh tokens should never flow to APIs. They are exchanged only between the client and the authorization server.
- Refresh cannot continue indefinitely without re-authentication: The bounds placed on refresh behavior are ultimately an implementer's decision, reflecting a trade-off between usability and security. It is sometimes assumed that refresh tokens allow access to be renewed indefinitely without user involvement. In practice, refresh behavior is governed by server policy, including absolute session lifetimes and re-authentication requirements.
- Access token expiration does not mean the user is logged out: When an access token expires, it affects only the client's ability to call APIs. It does not necessarily mean the user's client session has ended or that re-authentication is required. Clients often obtain new access tokens transparently, while the user remains signed in.
Final Thoughts
OAuth and OpenID Connect deliberately separate identity from access. ID tokens allow clients to understand who the user is. Access tokens allow APIs to decide what the caller is allowed to do. Although discussions often frame access tokens vs. ID tokens as a comparison, they are better understood as integral components of the same system, each with a distinct responsibility.
When these boundaries are respected, identity platforms can handle much of the protocol-level complexity for you. Tools such as Duende IdentityServer help enforce OAuth and OpenID Connect responsibilities by design, allowing application code to focus on business logic rather than token mechanics.
In browser-based applications, patterns like Backend-for-Frontend (BFF) can further simplify token handling by keeping access tokens on the application's backend server and reducing exposure in client-side code.