What it means
Single sign-on lets a user authenticate through a shared identity service and access multiple participating applications without independently signing in to each one every time. Applications typically rely on assertions or tokens that convey authentication information. Each application still decides the user's permissions and commonly maintains its own session.
Centralization can improve consistent authentication and account administration, while making the identity service an important dependency. The design must account for outages, compromised sessions, recovery, and applications that retain local sign-in paths. Single sign-on and federation are related concepts: federation describes trust and identity information exchanged between parties, while SSO describes the user's sign-in experience.
The idea at a glance / Identity
Shared sign-in. Separate application sessions.
Keep the provider, mail, and expense sessions visible together after one application’s logout. Their lifetimes and permissions are distinct.
Fictional campus: Nina signs in to CampusID at 09:00 UTC. Separate validated mail and expense sign-in flows create M7 and X8 using provider session I12. At 09:10, mail revokes M7 only; no coordinated logout is configured.
READ THE PICTURE
Read the separate scopes
After mail logout, M7 is refused while CampusID’s I12 and ExpenseDesk’s X8 remain active here. X8 can read Nina’s own D7 draft, but cannot approve another department’s claim. Shared sign-in did not create shared sessions or rights.
Keep in mindThis is one configured SSO snapshot, not a universal logout rule. Fresh-authentication requirements, provider failures, account disablement, revocation, and coordinated logout need their own checks.
Read the complete example
- Read the separate scopes. After mail logout, M7 is refused while CampusID’s I12 and ExpenseDesk’s X8 remain active here. X8 can read Nina’s own D7 draft, but cannot approve another department’s claim. Shared sign-in did not create shared sessions or rights. Nina’s required CampusID authentication was completed at 09:00 UTC. MailDesk then ran its own OIDC authorization-code flow at 09:01, receiving an assertion intended for client maildesk-web and establishing local session M7 after configured validation. At 09:02 ExpenseDesk ran a new, separate flow for expensedesk-web; policy allowed CampusID to reuse active provider session I12 without another authenticator prompt. The expense client validated its own sign-in result and established local session X8. Distinct issuer/subject associations map to separately provisioned mail and expense accounts under assumed account-linking arrangements; this does not require equal subject values at the two clients. At 09:10 mail invalidates M7 at the mail service. No front-channel/back-channel logout or other end-session signaling is configured in this authored example, so I12 and X8 are not invalidated by that action. Independent controlled requests with the old M7 and active X8 show mail content refused and Nina’s own expense draft D7 returned. ExpenseDesk separately refuses approval of claim D29 from another department under its own permission policy. The drawing shows a simultaneous snapshot and independent checks, not one credential passed from application to application. I12, M7, and X8 are safe correlation references, not cookie values. An assertion’s validity window is distinct from the resulting application session lifetime; ending a provider session also does not universally end relying-party sessions. A new mail sign-in or coordinated logout would require a separate completed process. All accounts and data are synthetic.
This is one configured SSO snapshot, not a universal logout rule. Fresh-authentication requirements, provider failures, account disablement, revocation, and coordinated logout need their own checks.
Diagram references: NIST SP 800-63C-4 - trust, identifiers, and separate sessions · OpenID Connect Core - issuer, audience, and flow validation
AN ILLUSTRATIVE SCENARIO
A university staff portal
A university connects its learning platform and expense system to a shared identity provider. A staff member signs in once, then opens both applications. The expense system still limits approvals to the staff member's assigned department. When an account is disabled after a departure, the administrator checks both applications rather than assuming every existing session ends immediately. The university also exercises a controlled recovery process for an identity-provider outage without leaving everyday bypass accounts unmanaged.
Put it to work
- Inventory participating applications, their trust configuration, local login alternatives, and who owns the identity provider and application sessions.
- Use maintained protocol implementations; validate the issuer (trusted identity provider), audience (intended application), signature, and time limits of received authentication information.
- Test sign-in, account disablement, session termination, and provider unavailability; document where application-specific action or emergency access is required.
How to check your work
Demonstrate the intended experience across two test applications, then disable the test identity and examine both new sign-ins and existing sessions. Record any delay or separate revocation step.
Connect the ideas
- Federation
Trusting authentication assertions from an external identity provider instead of storing every password locally.
- Authentication
The act of verifying a claimed identity with authenticators such as passwords, passkeys, or certificates.
- Authorization
The decision about whether a person, device, workload, or anonymous requester may perform a particular action on a resource.
- Session
State linking multiple requests; an authenticated session associates later requests with a previously authenticated identity until it expires or is revoked.