Skip to content
Aabha AI Academy

Stage 12 · L49

Distinguish shared identity, OAuth, OIDC and token purposes

Optional extension · expanded identity visuals; no released federation

Protocol study only. No federated login, callback, JWKS, refresh or SSO endpoint is implemented.

Federated sign-in lets an application rely on an identity provider rather than checking every password itself. The end user interacts through a browser/client; the application acts as relying party/OAuth client; the provider authenticates the user and issues its tokens; a resource API validates tokens intended for that API. These roles may be deployed separately even when one vendor serves several of them.

OAuth grants delegated access. OpenID Connect adds a sign-in protocol and ID token on top of OAuth. An ID token tells the intended client about authentication; an access token authorizes access to its intended resource. Sending an ID token to an API merely because it is signed confuses the audience and token purpose.

Scopes ask for permitted categories of access or identity information. Claims tell the recipient specific verified values such as issuer and subject. Asking for email does not turn an email address into a stable universal identity key, and a claim is trusted only after the token's validation boundary.

The current Equipment API implements local password/verification and HS256 access/action tokens. It has no OIDC redirect, discovery, client registration, code exchange or provider account link. This extension is complete protocol teaching, not an available federated login feature.

The independent exercise assigns each message to its recipient: authorization request to provider, code to registered callback, ID token to client, access token to the resource API. Explain which local responsibilities remain: creating/linking an application account, account state and record/action permissions.

User/browser initiates login; Relying party is the client; Provider authenticates identity; ID token → intended client; Access token → resource API
User/browser initiates login; Relying party is the client; Provider authenticates identity; ID token → intended client; Access token → resource API

Study the protocol primitive

Focused lesson example; see the end-of-stage capstone for the cumulative app

Authorization request → provider
Code → registered callback/client
ID token → intended relying party
Access token → intended resource API
Application account/permissions remain local.

Predict and observe this focused example using the concepts explained above. Its boundary is stated in the focused answer.

Guided protocol exercise

  1. Read the explanation and predict the focused example’s outcome.
  2. Assign each message to its recipient and explain why a signed ID token does not authorize an API rental read.
  3. Compare the observed outcome with the focused answer and state its boundary.

Expected: OAuth delegates access; OIDC adds authentication information for the intended client. The API accepts an access token intended for its resource/purpose, not any signed token. Scopes request categories; validated claims describe values. Local current account/action/record rules remain. This protocol exercise creates no federated endpoint.

  • A signed ID token is not automatically an API access token; scopes are requests, not proof that claims were validated.

Focused exercise and answer

Answer the protocol exercise before reading its solution. No new federation service is available.

Your transfer task: Assign each message to its recipient and explain why a signed ID token does not authorize an API rental read.

  1. Assign each message to its recipient and explain why a signed ID token does not authorize an API rental read.
Inspect the matching answer

This answer addresses the focused exercise above; the cumulative implementation is shown only after the stage prerequisites.

OAuth delegates access; OIDC adds authentication information for the intended client. The API accepts an access token intended for its resource/purpose, not any signed token. Scopes request categories; validated claims describe values. Local current account/action/record rules remain. This protocol exercise creates no federated endpoint.

Check your reasoning

Does OIDC choose which rental a user may read?

Show the explanation

No. Federated identity still maps to a local account whose current role and record scope control access.

Reading progress

54 lessons remain open to guests. Marking a lesson read records reading only; it does not award assessment credit or a certificate.

Device reading marks require browser storage. Reading is always available.

Sign in or create an account to save separate account progress. Your current page is kept.