2 min lesson

SP-initiated vs IdP-initiated

Walk through "SP-initiated vs IdP-initiated" in order, then name the proof that tells you it worked.

SP-initiated vs IdP-initiatedwhere the flow starts

The difference is just where the user begins: at the app itself, or at a tile in the IdP's dashboard. SP-initiated is the common, safer path; IdP-initiated skips the SP's request and is a frequent source of the dreaded "unsolicited response" error when the app expects a request it never made.

1SP-initiated. User hits the app, the SP redirects to the IdP with an AuthnRequest, the IdP authenticates them, then POSTs a signed assertion back to the SP's ACS URL.
2IdP-initiated. User clicks a tile in the Okta dashboard, the IdP POSTs an assertion to the SP cold, with no prior AuthnRequest. Apps that require a matching request will reject it as unsolicited.

Learn more

Advanced table

Inside the assertion

Inside the assertionthe fields you'll be asked to read

Element: NameID
What it carries: The user identifier the SP keys on: email, UPN or a persistent ID
Why it breaks logins: Format mismatch means the SP can't find the account

Element: AttributeStatement
What it carries: Claims: groups, first/last name, department
Why it breaks logins: Wrong attribute names break role mapping and JIT user creation

Element: Conditions / Audience
What it carries: Who the assertion is valid for, plus NotBefore/NotOnOrAfter
Why it breaks logins: An Audience that differs from the SP entity ID, or clock skew, voids it

Element: Signature
What it carries: The IdP's signature over the assertion or response
Why it breaks logins: Rotated/expired cert means signature validation fails

Base64-decode a real assertion into XML and you can point at the failing line.
Element	What it carries	Why it breaks logins
NameID	The user identifier the SP keys on: email, UPN or a persistent ID	Format mismatch means the SP can't find the account
AttributeStatement	Claims: groups, first/last name, department	Wrong attribute names break role mapping and JIT user creation
Conditions / Audience	Who the assertion is valid for, plus NotBefore/NotOnOrAfter	An Audience that differs from the SP entity ID, or clock skew, voids it
Signature	The IdP's signature over the assertion or response	Rotated/expired cert means signature validation fails

Base64-decode a real assertion into XML and you can point at the failing line.

Here is one decoded and trimmed. The SP is registered with the entity ID https://app.example.com/saml/sp, and exactly one line below does not match it.

Decoded assertion, trimmed; one line is wrong

<saml:Assertion>
  <saml:Issuer>https://idp.example.com/metadata</saml:Issuer>
  <ds:Signature>... valid, signed with the current cert ...</ds:Signature>
  <saml:Subject>
    <saml:NameID Format="...:emailAddress">jordan@example.com</saml:NameID>
  </saml:Subject>
  <saml:Conditions NotBefore="2026-03-02T09:00:00Z" NotOnOrAfter="2026-03-02T09:05:00Z">
    <saml:Audience>https://app.example.com/saml/metadata</saml:Audience>
  </saml:Conditions>
  <saml:AttributeStatement> ... groups ... </saml:AttributeStatement>
</saml:Assertion>

Signing vs encryption

Signing proves the assertion came from the IdP and wasn't altered; it's mandatory. Encryption hides the assertion contents from the browser that relays it and is optional, used when attributes are sensitive. Most break-fix work is signature-related, because certificates expire and rotate.

Learn more

Full explanation

The troubleshooting tree

The troubleshooting treesay this structure out loud

WALK THE SAML TROUBLESHOOTING TREE

1/6

Isolate scope: One user failing points at attributes or account state; the whole app failing points at shared config or a rotated cert. Scoping first tells you which branch of the tree to walk.

diagram: flow

Narrate this order; the signature/cert check is the gate that catches whole-app outages.

Interview move

Handed "user can't SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition. into Zoom," narrate the tree and read the assertion aloud in that order. "First I'd scope it: if every user fails, that points at shared config. I'd decode the assertion and check the signature first, since a rotated signing certificate is a common cause when a whole app goes dark. Here the signature validates against the current cert. The Audience is https://app.example.com/saml/metadata, but the SP is registered as https://app.example.com/saml/sp, so the SP rejects it at the Audience check. Timestamps and NameID look fine, so I'd fix the Audience in the IdP app config."

Scope first. Once you know the whole app is down, the rotated signing certificate is the first thing to name. A jump to "probably the cert" before you've scoped the failure sounds like luck.

Learn more

Optional practice

Test yourself on SP-initiated vs IdP-initiated

QAn entire app's SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition. breaks at once. Every user gets a signature-validation error. What's the most likely cause?

Learn more

Optional practice

Test yourself on SP-initiated vs IdP-initiated

QOne new hire can't sign in to an app while everyone else can. The decoded assertion's Audience matches the SP entity ID. What do you check next?

SP-initiated vs IdP-initiated

Step 1 of 3