Lesson 9 of 10 · About 4 minutes
Understand single sign-on
Learn the concept.
Single sign-on lets a trusted identity provider support sign-in to multiple applications. The application still decides what the signed-in person may do.
Follow a simplified SSO sign-in
Follow the sequence, or move one step at a time.
Reduced motion is on. Use Next step to explore without animation.
Read all 4 steps
- Open the application
The application directs the browser into the configured federation flow.
- Check identity
The provider authenticates the user or evaluates an eligible existing session.
- Validate the response
The application validates the provider response under the protocol, including issuer, intended recipient, and validity checks. Exchange details are simplified.
- Apply access and session rules
The application creates its session and applies permissions. Successful sign-in does not grant approval authority.
Three checks, three responsibilities
A fictional training example. Compare the observation with the conclusion.
- Identity provider
Authenticate the user and issue a sign-in response.
- Application
Validate the response and apply permissions.
- Session controls
Manage provider and application sessions explicitly.
Read the visualA user signs in successfully through SSO. What determines whether they can approve an expense?
Authentication establishes identity; application authorization governs actions.
Know the two roles
The identity provider verifies the user. The application, also called the relying party, validates the sign-in response from that provider.
Separate sign-in from permission
In a simplified federated flow, the application checks a signed assertion or ID token, including the intended recipient and validity. SAML and OpenID Connect are common federation protocols. An access token serves a different purpose from an ID token.
Check each session
The provider and application can maintain separate sessions. Ending the provider session does not necessarily end existing application sessions. Verify logout and revocation behavior for the actual integration.
Put it in context
Fictional case: Maya signs in through the company provider and reaches the expense application. Her employee role allows submitting a claim but not approving one. Successful SSO did not make her a finance administrator. During offboarding, the team checks both central identity access and outstanding application sessions.
Make a decision.
Use what you just learned. A correct answer lets you save this lesson to your progress.
Take this with you.
One sign-in experience still involves trust checks, application permissions, and session controls.
Next lesson: Stop an MFA fatigue attack