SAML 2.0 came out of the Security Services Technical Committee at OASIS, and the standard defines an XML-based framework for exchanging security information between online business partners (OASIS SAML overview). OpenID Connect describes itself as "a simple identity layer on top of the OAuth 2.0 protocol" (OpenID Connect Core). Following one login through each shows where they differ.

A SAML login, step by step

Take the flow the OASIS overview calls SP-initiated. The user tries to open a page on your product (the service provider) and has no session. Your product redirects the browser to the identity provider's sign-in service, carrying an authentication request in a URL parameter named SAMLRequest, along with a RelayState value that remembers where the user was going. If the user isn't already signed in at the identity provider, they're challenged for credentials there.

Then the identity provider builds a SAML assertion describing the user's login. Under the POST binding, the assertion is digitally signed, placed inside a Response message, base64-encoded and put into a hidden form field called SAMLResponse. The overview notes that the form typically comes with script code that posts it to your product automatically. Your product checks the signature on the assertion, creates a local session, and sends the user on to the page they asked for.

The overview describes a second route as well, IdP-initiated SSO, where the user is already at the identity provider and selects your product from a menu or link there. The identity provider builds the signed assertion and sends the user's browser to your product with it. The SAML profiles document calls this an "unsolicited <Response>" and says it must not carry an InResponseTo attribute, which the SAML core specification defines as a reference to the identifier of the request the response corresponds to (SAML profiles, section 4.1.5; SAML core, section 3.2.2).

The same login in OIDC

OpenID Connect is built on OAuth 2.0 (see what OAuth is), so the opening moves will look familiar. In the Authorization Code Flow, your application (the OIDC docs call it the relying party) sends the browser to the provider with a client ID, a redirect URI and a scope that must include "openid". The spec says that if the openid scope is missing, the behaviour is entirely unspecified. The redirect URI has to exactly match one the client pre-registered at the provider.

Once the user has signed in, the provider returns an authorization code, and your application exchanges it at the token endpoint for an ID token and an access token. The ID token is a JSON Web Token carrying claims about the login. The required ones in the spec are the issuer (iss), a subject identifier (sub) that's never reassigned within that issuer, the audience (aud), which has to include your client ID, an expiry time (exp) and an issue time (iat).

So the browser in SAML carries a signed XML document straight to your product, while in OIDC it carries a code that your application exchanges for tokens at the provider's token endpoint. The vocabulary shifts too: the OpenID Foundation's guide calls the identity provider an OpenID Provider (OP), and Microsoft's documentation notes that an authorization server is also called an identity provider.

What the admin sets up

Both sides need to trade configuration, and each spec has its own way of publishing it. SAML uses metadata, XML documents that can describe an entity's supported bindings, its role (identity provider or service provider), its identifiers and its keys for signing and encryption. OIDC providers that support Discovery must serve a JSON document at the issuer's address with /.well-known/openid-configuration added, and the OpenID Foundation's guide adds that a client must be registered with the provider. The ACS URL, entity ID and signing certificate that a SAML admin swaps with your product are listed in how to answer SSO questions.

What to confirm for a buyer

Which standard your product supports, or whether it supports both, is a fact about your product, whatever the buyer's identity provider offers.

If an admin asks whether employees can open your product from their identity provider's app menu, that is the IdP-initiated route above. The OASIS overview defines both flows, and your documentation should say which ones your product accepts.

Whether the buyer can require a stronger login has a counterpart in each standard. In SAML, the OASIS overview says a service provider can include an authentication context in its request to ask for specific authentication requirements, such as multi-factor authentication. In OpenID Connect, the optional acr_values request parameter asks the provider to use particular Authentication Context Class Reference values.

On devices, the OpenID Foundation's FAQ says OpenID Connect works for native and mobile apps, and the OASIS overview describes its browser profile as working with commercial browsers that have no special capabilities. If a buyer's users sign in to a mobile app, check which of your login paths that app uses.

Session length is where the OIDC spec adds a note: the ID token's expiration time is unrelated to the lifetime of the authenticated session between the app and the provider. So the token's expiry doesn't answer how long people stay signed in; find that separately.