SAML, now at version 2.0, is an OASIS standard in which the customer’s identity provider signs an XML assertion saying who the user is, and your application, the service provider, verifies the signature and signs the user in. The browser carries the assertion to your assertion consumer service URL, usually through the HTTP-POST binding, and the two sides trust each other through metadata they exchange at setup and again whenever a certificate rotates: entity IDs, that URL and the signing certificate. The rules are in the OASIS SAML Core specification, the SAML Bindings specification, the SAML Metadata specification and the SAML Profiles specification, whose Web Browser Profile defines the browser sign-in flow described here.
In an FDE interview
SAML sits on the identity-protocol list of all three Okta postings, as of September 2026. Source 1Senior Forward Deployed Engineer - Okta for AI AgentsPublisherOkta (Greenhouse)Source typecompany job postingSource 2Principal Forward Deployed Engineer - Okta for AI AgentsPublisherOkta (Greenhouse)Source typecompany job postingSource 3Principal Forward Deployed Engineer (Singapore)PublisherOkta (Greenhouse)Source typecompany job posting It comes up whenever a customer’s employees must reach what you deployed, as in designing sign-in through a large customer’s identity provider. A strong answer says SAML proves who someone is at sign-in and nothing more: it does not create the account, and it does not remove it when they leave, so you pair it with SCIM. Load the identity provider’s metadata from its URL and refresh it on a schedule, or a certificate rotation will lock every user out. Then name the details that break go-lives: the NameID format, the group attributes you map to roles, and whether you accept IdP-initiated sign-in at all.
On the code side, use a maintained SAML library instead of parsing XML yourself, verify that the signature covers the exact assertion you read, because signature-wrapping attacks slip an unsigned one beside it, and check Audience, Destination, NotOnOrAfter and InResponseTo (OWASP SAML Security Cheat Sheet). IdP-initiated sign-in has no request for InResponseTo to match, which opens the door to replay and login CSRF, so if a customer insists on it, keep the validity window short and reject any assertion ID you have already seen.
The lesson Identity and network in someone else’s environment walks through the full sign-in path.