What it means
OpenID Connect adds an identity assertion on top of OAuth. The identity provider authenticates the subject and issues an ID token, usually alongside an access token. The ID token says the provider completed a sign-in for this client. The application validates the issuer, the audience, the signature, and the time limits, then creates its own session. The access token, not the ID token, is what a resource server should see for an API call.
An ID token does not authorize a shipment export, a role change, or a second application that was not the audience. It also does not prove which person held the device. Federation still needs the relying party to map the subject to local permissions. Single sign-on may follow, but each application keeps its own session and its own authorization rules.
The idea at a glance / Identity
An ID token names its intended client.
Compare one received sign-in statement at its intended client and another client. Correct issuer and signature do not erase an audience mismatch.
Authored id.chronos.orbital token T14: subject rs-sub-42, audience chronos-hub, issued 10:00 and expiring 10:05 UTC. At 10:02 its issuer, signature, and time checks pass. Chronos Hub’s own flow also passes nonce binding and maps the subject to FL-17.
READ THE PICTURE
Read the separate scopes
Chronos Hub accepts T14 only after its configured sign-in checks, then creates session FS21. Testbench requires testbench, so it refuses the same chronos-hub audience. Chronos Hub still allows assigned R8 and refuses R99; the ID token is not an API access token.
Keep in mindThe picture is a claim/check summary after receipt, not a serialized JWT or complete login flow. Cryptographic checks are assumed. An ID token does not authenticate the current presenter or authorize an API call.
Read the complete example
- Read the separate scopes. Chronos Hub accepts T14 only after its configured sign-in checks, then creates session FS21. Testbench requires testbench, so it refuses the same chronos-hub audience. Chronos Hub still allows assigned R8 and refuses R99; the ID token is not an API access token. This synthetic comparison assumes a completed OIDC authorization-code flow returning an ID token to Chronos Hub over verified TLS. T14 is a safe token reference, never its serialized value. The exact configured issuer and iss value are https://id.chronos.orbital; sub is rs-sub-42, aud is the single client identifier chronos-hub, iat is 10:00 UTC, and exp is 10:05 UTC on the authored test day. The times are decoded labels, not literal JWT string encodings. At 10:02 UTC the expected issuer, allowed signing algorithm/key, signature, and time requirements pass. Chronos Hub also verifies its requested nonce and transaction binding, with any other configured flow requirements satisfied. The (id.chronos.orbital, rs-sub-42) pre-provisioned mapping identifies account FL-17, after which Chronos Hub creates local session FS21. A separate controlled validation at Testbench does not find its client identifier testbench in aud, so that token cannot establish a Testbench session. Its valid issuer, signature, and time checks remain valid; the audience failure is sufficient for refusal and is not repaired by a signed token. Further Testbench transaction checks are not claimed complete, and no already-existing Testbench session is invalidated by this test. Inside Chronos Hub, independent policy tests with FS21 return a copy of assigned route R8 and refuse unassigned R99 while retaining original records. These are local application checks, not ID-token grants. The API credential for a protected OAuth resource call is an appropriate access token; an ID token’s audience is its relying client. This is neither proof of which human currently holds a device nor a complete OIDC protocol or JWT-validator test. Token issuance, refresh, discovery, key rotation, and all other flow variants require their own verification.
The picture is a claim/check summary after receipt, not a serialized JWT or complete login flow. Cryptographic checks are assumed. An ID token does not authenticate the current presenter or authorize an API call.
Diagram references: NIST SP 800-63C-4 - trust, identifiers, and separate sessions · OpenID Connect Core - issuer, audience, and flow validation
AN ILLUSTRATIVE SCENARIO
The telemetry edge takes an ID token
Kael signs in through Meridian’s identity provider. The telemetry edge validates an ID token whose audience is the telemetry edge, then opens a session for Kael’s account. The same token presented to Chronos Hub must fail the audience check. Inside the telemetry edge, Kael can see assigned passes only. The ID token proved a sign-in to the identity provider. It did not grant satellite 99, and it is not the credential Chronos Hub’s export API should accept.
Put it to work
- Separate the ID token, which asserts authentication to this client, from the access token, which a resource server may accept for a limited API call.
- Validate issuer, audience, signature, and expiry with a maintained library. Reject a token minted for another application.
- Map the subject to local permissions. Test sign-in, an unassigned action, a wrong-audience token, and what happens to the application session when the account is disabled.
How to check your work
Sign in to a test client and confirm the ID token audience matches that client. Confirm a second client rejects it. Confirm an authenticated session still receives a denial for an unassigned record.
Connect the ideas
- OAuth
A delegated-access framework: a client presents an access token so a resource server can allow a limited action. The token is not proof of who the human is, and it does not grant every action the API could perform.
- Federation
Trusting authentication assertions from an external identity provider instead of storing every password locally.
- SSO
A pattern where one authentication to an identity provider is reused across multiple applications.
- Authentication
The act of verifying a claimed identity with authenticators such as passwords, passkeys, or certificates.