Stage 12 · L52
Understand refresh, SSO and local permissions
Optional extension · expanded identity visuals; no released federation
Protocol study only. No federated login, callback, JWKS, refresh or SSO endpoint is implemented.
A refresh token can obtain a new access token under the authorization server's policy. It is a credential with its own storage, lifetime, client binding and revocation requirements. It must not be accepted as an API access token or casually placed in a URL, log or browser source file.
Rotation replaces a used refresh token and can detect reuse of an old token. Family revocation and race handling require an atomic server-side policy. A provider may own that policy; the application must still store and use tokens safely. This revision implements neither refresh storage nor a rotation endpoint, and its local credential-version check is not a refresh service.
SSO reuses an identity-provider browser session to authenticate another relying party without asking for the password again. Each application still has its own local account/session and permission decisions. Signing out of one application does not automatically prove all provider/other-application sessions ended; logout propagation is an additional supported protocol/design.
Federation changes credential verification and token trust, but does not remove local active-account checks, role management, rental ownership, capacity rules or audit policy. A current provider session cannot authorize a forbidden check-in or silently promote a local role.
The independent exercise maps provider session, application session, access token and refresh token lifetimes, then asks which boundary must reject a disabled local account. Treat refresh, SSO and logout coordination as explicit optional concepts requiring a chosen provider, client registration and approved implementation before any availability claim.
Study the protocol primitive
Focused lesson example; see the end-of-stage capstone for the cumulative app
Provider session can enable SSO across relying parties.
Refresh token renews permitted access under its own policy.
Local account state, current role and record scope still govern this API.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.
- Explain provider logout, local logout and a local role change without claiming a shared implementation.
- Compare the observed outcome with the focused answer and state its boundary.
Expected: They affect different sessions/tokens. A provider session may reduce repeated sign-in, while a local logout does not universally revoke every provider/API token. Refresh is a separate credential/policy with rotation/replay concerns. Current local role/account checks still apply. No refresh or SSO endpoint is implemented here.
- Provider session is not local permission; local logout need not terminate every other session; refresh credentials have their own trust boundary.
Focused exercise and answer
Answer the protocol exercise before reading its solution. No new federation service is available.
Your transfer task: Explain provider logout, local logout and a local role change without claiming a shared implementation.
- Explain provider logout, local logout and a local role change without claiming a shared implementation.
Inspect the matching answer
This answer addresses the focused exercise above; the cumulative implementation is shown only after the stage prerequisites.
They affect different sessions/tokens. A provider session may reduce repeated sign-in, while a local logout does not universally revoke every provider/API token. Refresh is a separate credential/policy with rotation/replay concerns. Current local role/account checks still apply. No refresh or SSO endpoint is implemented here.Check your reasoning
Can a provider's SSO session bypass a disabled local account?
Show the explanation
No. The application must still enforce current local state and its action/record rules.
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.
Your earlier place on this device suggests these lessons. No new lesson is marked read.