SAML and OIDC

SAML is widely used for legacy enterprise SSO. It uses XML documents called assertions to tell your app, the service provider, what the IdP verified about the user.

OIDC is an identity layer built on OAuth 2.0. Its ID tokens are JWTs, and the protocol fits naturally into web, mobile, and API architectures that already use OAuth.

Both can solve the same SSO problem, but their message formats, flows, and validation rules are different.

SAML flow:

1. The user visits your app.
2. Your app redirects the user to the IdP.
3. The user logs in with the IdP.
4. The IdP returns a SAML response through the browser to your app's assertion consumer service.
5. Your app validates the response and assertion before creating a local session.

OIDC flow:

1. The user visits your app.
2. Your app creates request-binding values like state, nonce, and a PKCE challenge, then redirects the user to the IdP.
3. The user logs in with the IdP.
4. The IdP redirects back with an authorization code.
5. Your app verifies the callback and exchanges the code for tokens, including an ID token.
6. Your app validates the ID token, including its nonce, before creating a local session.

The important detail is that your app should not ask for the user's password. The IdP handles authentication; your app validates the result. For an OIDC ID token, that includes its signature, issuer, audience, expiration, and nonce when one was sent. Don't trust identity claims until the protocol response passes every required check!