SAML
The XML-based login protocol many large companies use to let employees enter your app with their work account.
What it is
SAML 2.0, an OASIS standard since 2005, is the XML protocol behind a lot of enterprise SSO. The identity provider, such as Okta or Microsoft Entra ID, authenticates the employee and sends your app a signed assertion containing an identifier and attributes. The browser usually carries that assertion to your Assertion Consumer Service as a base64-encoded SAMLResponse.
Reach for it when a company asks to connect its directory login to your app. OIDC is easier for a new system, but large customers still ask for SAML by name, so B2B products commonly support both. Each customer connection brings an IdP metadata document, signing certificate, issuer, and attribute mapping.
The gotcha is validation. Do not merely decode the XML and trust the email inside it. Verify the XML signature with a maintained library, then check issuer, audience, recipient, destination, time conditions, and InResponseTo when the flow started at your app. Reject replayed assertion IDs, and allow only a small clock-skew window.
Ask AI for it
Implement this app as a SAML 2.0 service provider. Expose SP metadata with a stable entityID and Assertion Consumer Service URL, accept each customer's IdP metadata XML, and use a maintained SAML library such as @node-saml/node-saml or python3-saml for XML signature validation rather than hand-rolling it. Support SP-initiated login with a random request ID and RelayState. At the ACS endpoint, validate the signed Response or Assertion, issuer, AudienceRestriction, Recipient, Destination, NotBefore, NotOnOrAfter, and InResponseTo before creating a session. Persist assertion IDs until expiry to block replay, allow no more than two minutes of clock skew, map NameID and configured attributes to the local user, and return a clear configuration error when metadata or certificates are invalid.