- Client requests the openid scope
- OpenID Provider returns an ID token through code redemption
- Client validates identity claims before creating a session
Look at the recipient of each token before looking at its payload. The access token is for a resource API. The ID token is for the client that requested authentication. Both can arrive in the same token response, and that proximity is exactly why implementations sometimes confuse them.
If generated code passes an ID token to an unrelated API or accepts a provider access token as your app’s session, the names may look plausible while the trust boundary is wrong. Start the review with intended recipients, then inspect the validation.
The difference shows up in what the client can conclude
OAuth gives the client access to protected resources. OIDC additionally gives the client a defined authentication result. OpenID Connect Core §1 describes this as an identity layer on OAuth 2.0.
| Question | OAuth 2.0 | OpenID Connect |
|---|---|---|
| Primary job | Obtain authorized access to resources | Authenticate a user to a client |
| Main artifact | Access token | ID token, alongside an access token in code flow |
| Intended token recipient | Resource server | Client for the ID token |
| Standard user identity claims | Not defined by the base framework | Defined claims including issuer and subject |
| Profile retrieval | Provider-specific resource APIs | Standard UserInfo endpoint when provided |
| Creates your local session? | No | No |
OIDC isn’t a competing grant you select instead of OAuth. An OIDC authorization-code request uses OAuth’s redirect and code-redemption machinery, with the openid scope and additional identity rules. You can need both identity and API access in the same integration.
The reverse isn’t true: an OAuth server doesn’t become an OpenID Provider just because it returns JSON about a person. A documented profile API can support a provider-specific login, but it doesn’t by itself supply the interoperable ID-token contract.
Keep the same flow and add identity validation
OIDC code flow returns a code through the browser and tokens through the token endpoint. The authorization code reference covers that sequence; PKCE binds redemption to the initiating transaction.
The identity-specific work starts when the client processes the ID token. It must apply the provider’s permitted algorithms and validation rules, verify the expected issuer and audience, check expiration, and verify the signature using trusted provider keys as required by the integration. If the request included a nonce, the returned nonce must match the saved transaction value.
- Trusted provider keys establish who signed the ID token.
- Issuer, client audience, expiry, and transaction nonce establish where and when it belongs.
- The validated issuer and subject identify the account to map locally.
A signature alone isn’t enough. A genuine token issued for a different client shouldn’t log someone into yours. Neither should a token from an unexpected issuer, even if its subject looks familiar. The exact checks belong in a maintained OIDC library configured for the provider, rather than a hand-written “decode JWT” helper.
OIDC’s UserInfo response has another binding to check: its sub must match the ID token’s subject before you use the extra profile claims. Otherwise, combining two individually plausible responses can attach one account’s attributes to another account.
Subject identifies the account; email describes it
Use the issuer and subject together as the OIDC identity key. The subject is unique within its issuer’s context, not across every provider in the world. OIDC also supports pairwise subjects, so you shouldn’t assume unrelated clients receive the same identifier for the same person.
Email, display name, and avatar are attributes. They can change or be absent, and email verification is a separate claim with specific semantics. OIDC Core §5.7 explicitly warns against using email as a unique identifier.
For an application that supports multiple providers, an equal email doesn’t prove that the two provider accounts should be linked. Linking changes who can enter an existing local account. Make it an explicit authenticated operation with a defined policy, not a side effect of profile normalization.
Google and GitHub don’t produce identical identity evidence
AnyOAuth uses Google’s OIDC identity validation and GitHub’s OAuth-backed fresh profile and email lookup. GitHub OAuth sign-in in this integration doesn’t return an OIDC ID token. The service can normalize the resulting profile shape without claiming the two upstream protocols are identical.
At the customer boundary, your backend retrieves the normalized identity from AnyOAuth’s profile API. It receives an opaque profile token, not an upstream ID token to validate or a provider access token to reuse.
The service does the upstream identity work; your application trusts its documented profile handoff. That is a different contract from configuring an OIDC issuer and validating its ID tokens locally.
AnyOAuth isn’t currently a customer-facing OIDC provider: it doesn’t offer customer discovery or ID tokens. If your integration expects an OIDC issuer, use an actual OIDC provider contract. The docs describe the supported profile handoff rather than an interchangeable OIDC configuration.
Authentication finishes before application authorization does
A validated identity tells your backend which account authenticated. It doesn’t decide organization membership, database permissions, or whether a suspended user may enter. Your app maps the subject, applies its own policy, and creates a session with its own lifetime.
Consequently, an ID token’s expiration isn’t a command to expire every local session at the same instant. AnyOAuth’s profile-token expiration is likewise independent of your app session. You still need local logout, revocation, and authorization checks after the provider round trip has finished.
For the broader vocabulary, start with what OAuth does. For enterprise federation, OAuth versus SAML explains why OIDC is the closer login comparison. The security model is the place to check the concrete AnyOAuth boundary before assigning capabilities based on protocol names.
Sources
Primary references retrieved 2026-10-06:
- OpenID Foundation, OpenID Connect Core 1.0, especially §§2, 3.1.3.7, 5.3.2, and 5.7.
- IETF, RFC 6749: The OAuth 2.0 Authorization Framework, especially §§1.4 and 4.1.
- IETF, RFC 9700: Best Current Practice for OAuth 2.0 Security, especially §2.1.