Single Sign-On (SSO) Fundamentals
Single Sign-On (SSO)
This domain tests how Okta federates authentication to applications and how sign-on policies decide whether a user is allowed, challenged, or denied. Expect SAML, OIDC, SWA, app assignment, and IdP- versus SP-initiated flows.
Core rules
- SAML 2.0: Okta is the identity provider (IdP); the app is the service provider (SP). Okta sends a signed assertion to the SP's Assertion Consumer Service (ACS) URL. The audience URI must match the SP entity ID. Attribute statements map Okta profile values to SAML attributes; NameID identifies the user.
- OIDC: Okta returns an ID token and access token. The redirect URI must be registered exactly; scopes such as openid, profile, and email control claims.
- SWA (Secure Web Authentication): Okta stores the app username and password and submits them; it is used when the app cannot federate. Bookmark apps only launch a URL.
- SP-initiated SSO starts at the app and redirects to Okta; IdP-initiated SSO starts in the Okta dashboard and posts to the app.
- App assignment controls who sees and can use the app; sign-on policies add conditions and MFA requirements.
Worked example
An admin configures a SAML app with ACS URL https://app.example.com/saml/acs and audience https://app.example.com. The app rejects the assertion with "Invalid audience." Reasoning: the audience URI in Okta must exactly match the SP entity ID; a trailing slash or different host breaks validation. The admin corrects the audience, assigns the Engineering group, and tests an SP-initiated login.
Traps
Do not swap ACS URL and audience URI. A correct signature does not fix a mismatched audience. SWA is not federation; it stores credentials. IdP-initiated SSO can fail if the SP requires a relay state or does not accept unsolicited assertions. Assigning a user directly and through a group does not create two accounts.