Stage 12 · L51

Trust the issuer and link a validated federated identity

Optional extension · expanded identity visuals; no released federation

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

JWKS publishes verification keys for a configured issuer. The verifier obtains them from trusted metadata and chooses a compatible key, commonly by kid. An incoming jku/x5u URL or unverified issuer must not direct arbitrary key fetching. A token cannot bring its own trust root.

A correct signature proves only that the selected key signed the data. Also check the configured issuer, intended audience, accepted algorithm/key type, expiration/not-before and the token's intended use. For an ID token, check the expected nonce and any additional client/provider validation requirements. A token meant for another client/resource remains invalid even with a valid signature.

Key rotation needs bounded refresh/cache behavior. An unknown kid may justify a controlled refresh from the configured issuer, not an unbounded fetch per hostile request or acceptance of any advertised key. This course supplies no live discovery/JWKS cache or third-party JWT adapter.

Link a federated identity by the stable pair (issuer, subject), not email alone. Different issuers can use the same subject text, and email can change or be reassigned. An existing local account link needs an explicit verified policy; automatic email matching can connect the wrong person. Provider email_verified is a claim under that provider's trust boundary, not a universal link authorization.

The independent exercise compares two identities with the same email but different issuer/sub pairs and chooses a safe linking decision. Then reject a correctly signed wrong-audience token in the reasoning table. The local course JWT tests demonstrate the general audience/issuer principle with a fixture secret, but they do not certify a real provider's JWKS or account-linking implementation.

Keys from configured issuer; Verify signature + claims/purpose; Never trust incoming key URLs; Local identity: (issuer, subject); Email alone does not link accounts

Study the protocol primitive

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

Configured trusted issuer → matching metadata/JWKS
Select permitted key/algorithm → verify signature and required claims
Validate audience/time/nonce → link by (issuer, subject)
Current local account/permission check follows.

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

Guided protocol exercise

Read the explanation and predict the focused example’s outcome.
Reject token-chosen issuers/keys and email-only linking. Explain why signature validity alone is insufficient.
Compare the observed outcome with the focused answer and state its boundary.

Expected: Fetch keys only from configured trusted issuer metadata; never let an unverified token choose an arbitrary endpoint. Check algorithm/key, signature, issuer, intended audience, time and expected nonce before linking issuer+subject. Email can change and collide across issuers. This is a reasoned design, not an installed JWKS/linking endpoint.

Valid signature alone is insufficient; email is not a universal identity key; incoming key URLs cannot establish trust.

Focused exercise and answer

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

Your transfer task: Reject token-chosen issuers/keys and email-only linking. Explain why signature validity alone is insufficient.

Reject token-chosen issuers/keys and email-only linking. Explain why signature validity alone is insufficient.

Inspect the matching answer

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

Fetch keys only from configured trusted issuer metadata; never let an unverified token choose an arbitrary endpoint. Check algorithm/key, signature, issuer, intended audience, time and expected nonce before linking issuer+subject. Email can change and collide across issuers. This is a reasoned design, not an installed JWKS/linking endpoint.

Check your reasoning

What is the federated identity key for local linking?

Show the explanation

The configured issuer and its subject as a pair, under an explicit linking policy; email alone is insufficient.

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.