Category: Tokens & Sessions
ID Token
Also known as: Identity Token
Simply put
An ID token is a piece of data issued after a user signs in that serves as proof the user was authenticated. It was introduced by OpenID Connect, an authentication standard, and is intended to be read by the application that requested the sign-in. It typically carries basic information about the user, such as an identifier and, depending on configuration, attributes like name or email.
Formal definition
An ID token is a security artifact defined by OpenID Connect (which layers authentication on top of OAuth 2.0) that represents the outcome of an authentication event and is intended for consumption by the OIDC client (relying party) rather than for authorizing access to a resource server (a role served by access tokens). It is a JSON Web Token (JWT) whose payload consists of claims about the authenticated user and the authentication event. Per OpenID Connect Core 1.0, the required claims typically include iss (issuer), sub (subject identifier), aud (audience), exp (expiration), and iat (issued-at), with nonce required in certain flows; additional claims such as name or email may be present depending on scopes and configuration. Note that a JWT-based ID token is typically signed for integrity and authenticity, which is distinct from being encrypted for confidentiality; encryption is optional and deployment-dependent. Validation of an ID token (signature, issuer, audience, expiry, and nonce where applicable) is a runtime concern for the client and is out of scope for this definition beyond noting its necessity.
Why it matters
The ID token is the artifact that answers the question "was this user authenticated, and by whom?" It is the point where OpenID Connect delivers on its purpose as an authentication layer over OAuth 2.0. Because it is intended for the OIDC client (the relying party) rather than a resource server, it lets an application establish a local session based on a trustworthy statement about an authentication event, rather than inferring identity from an access token that was never designed to carry that meaning. Conflating the two is a common and consequential mistake: using an access token as proof of authentication, or forwarding an ID token to a resource server as if it were an authorization credential, breaks the intended trust boundaries of the protocol.
Who it's relevant to
Application and relying party developers
Developers integrating OpenID Connect consume ID tokens to establish authenticated sessions. They need to read the token's claims, distinguish it from an access token, and implement validation of signature, issuer, audience, expiry, and nonce where applicable rather than trusting the token at face value.
Security architects
Architects designing federated sign-in flows must enforce the boundary between authentication artifacts (ID tokens, for the client) and authorization artifacts (access tokens, for resource servers). They also decide whether ID token encryption is warranted in addition to signing, based on the confidentiality needs of the deployment.
IAM engineers configuring identity providers
Engineers configuring an OIDC provider control which claims appear in the ID token through scopes and provider settings, and they manage signing keys and, where used, encryption. Because required claims and issuance behavior vary by provider and profile, they verify their specific platform's output against the OpenID Connect Core baseline.
Auditors and compliance reviewers
Reviewers assessing an authentication implementation examine whether ID tokens are validated correctly and whether the distinction between authentication proof and authorization grant is respected. Weak or absent validation of issuer, audience, or signature is a finding worth flagging.
Inside ID Token
iss (Issuer)
A required claim identifying the issuer of the ID Token, typically the OpenID Provider's URL. Relying parties validate this value to confirm the token came from the expected authorization server.
sub (Subject)
A required claim containing a locally unique and stable identifier for the authenticated end-user within the issuer's context. It represents who was authenticated, which is the core purpose of the ID Token under OpenID Connect.
aud (Audience)
A required claim identifying the intended recipient(s) of the token, typically including the client_id of the relying party. Clients must verify they are among the audience values or reject the token.
exp (Expiration Time)
A required claim specifying the time after which the ID Token must not be accepted. Enforcing this limits the window in which a captured token can be used.
iat (Issued At)
A required claim indicating the time at which the token was issued, which relying parties can use to assess token age and freshness.
nonce
A claim that echoes the value the client sent in the authentication request. It is required in certain flows (for example the implicit flow) and is used to mitigate replay attacks by binding the token to a specific request.
JWT structure
In OpenID Connect, the ID Token is represented as a JWT consisting of a header, a payload of claims, and a signature. Being signed provides integrity and authenticity but does not by itself provide confidentiality; a signed token is not the same as an encrypted one.
Optional identity claims
Depending on requested scopes and provider configuration, the token may include additional claims such as name, email, or other profile attributes. The specific set varies by deployment and profile.
Common questions
Answers to the questions practitioners most commonly ask about ID Token.
Can an ID token be used to authorize access to an API or resource server?
No. An ID token is an authentication artifact issued by OpenID Connect to convey that a user has been authenticated, along with claims about that authentication event. It is intended for the client (relying party) that requested it, not for presentation to a resource server. Authorization to call an API is the job of the access token, which OAuth 2.0 issues for delegated authorization. Using an ID token as an access token conflates authentication with authorization and is generally discouraged; the aud claim of an ID token identifies the client, not an API audience. Behavior can vary by deployment, but the OIDC design intent keeps these two token types distinct.
Since an ID token is signed as a JWT, does that mean its contents are protected from being read?
No. Signing and encryption are different protections. An ID token is typically a signed JWT (a JWS), which provides integrity and lets the client verify the issuer and detect tampering. Signing does not hide the payload, the claims in a standard signed JWT are Base64URL-encoded, not encrypted, and can be decoded and read by anyone who holds the token. OpenID Connect does define an optional encrypted form (a JWE), but unless that encryption is explicitly applied in a given configuration, the claims should be treated as readable. Do not place data in an ID token that you would not want the client or an interceptor to see.
Which claims must a relying party validate in an ID token, and what does the required set include?
OpenID Connect Core 1.0 defines a minimum set of required claims in an ID token: iss (issuer), sub (subject identifier for the end user), aud (audience), exp (expiration time), and iat (issued-at time). In certain flows a nonce claim is also required, and additional claims such as auth_time or acr may be required depending on the request. A relying party should typically verify the token signature, confirm iss matches the expected issuer, confirm its own client identifier is present in aud, check that the token has not expired via exp, and, when a nonce was sent in the authentication request, confirm the returned nonce matches. Exact validation steps depend on the flow and profile in use.
How should a client handle the difference between the sub claim and a human-readable identifier like email?
In most OpenID Connect deployments the sub claim is the stable, unique identifier for the end user within the scope of the issuer, and it is generally the value a client should key user accounts on. Human-readable claims such as email or preferred_username can change over time and are not guaranteed to be unique or permanent across a provider's user base. Relying on email as a primary key can create account-linking and security problems if it is reassigned. The precise uniqueness and stability guarantees depend on the identity provider, so consult provider documentation before treating any claim other than the sub (typically paired with the iss) as a durable user key.
Should an ID token be sent to backend services or used across service boundaries?
Typically no. The ID token's audience (aud) is the client that requested authentication, so it is intended for consumption at the relying party rather than forwarding to downstream APIs or microservices. For calling backend services, the appropriate credential is generally an access token scoped for that service. Passing ID tokens between services blurs authentication and authorization concerns and may fail audience validation at the receiving end. If backend services need identity context, that is usually handled through access tokens, token exchange, or separate mechanisms rather than reusing the ID token, though specifics depend on your architecture and provider.
What is the relationship between the ID token and the UserInfo endpoint for obtaining user claims?
An ID token carries a set of claims about the authentication event and the user directly in the token, while the UserInfo endpoint is an OAuth 2.0 protected resource that a client can call with an access token to retrieve additional claims about the authenticated user. In many deployments the ID token contains a smaller core set of claims and the UserInfo endpoint supplies fuller profile information, though a provider may choose to include more claims in the token itself. Which approach applies depends on provider configuration and the scopes requested. When comparing claims from both sources, the sub value returned should match, and clients should verify that consistency.
Common misconceptions
An ID Token and an access token are interchangeable and can be used the same way.
They serve different purposes. The ID Token is an authentication artifact from OpenID Connect asserting that a user was authenticated and is intended for the client. An access token is an OAuth 2.0 authorization artifact used to call protected resources. Using an ID Token as a bearer credential against APIs is a misuse of its intended scope.
Because an ID Token is signed, its contents are protected from being read.
Signing provides integrity and authenticity, not confidentiality. Unless the token is also encrypted, its claims can be read by anyone who obtains it. Signing and encryption are distinct protections.
The presence of an ID Token alone proves the client is authorized to access a given resource.
An ID Token addresses authentication, establishing who the user is. Authorization decisions about what a principal may do are handled separately, typically via access tokens and enforcement points, and are out of scope for what an ID Token asserts.
Best practices
Validate all required claims on receipt, including iss, sub, aud, exp, and iat, and reject tokens that fail any check.
Verify the token signature against the issuer's published keys and confirm the algorithm matches expectations before trusting any claim.
Confirm the aud claim includes your client_id and reject tokens intended for other audiences.
Where the flow requires it, generate and verify the nonce to bind the token to your original authentication request and mitigate replay.
Do not use the ID Token as a credential to call protected resources; use an access token for authorization to APIs.
If claims within the token are sensitive, apply JWT encryption in addition to signing, since a signed token is not confidential by itself.
