Sooner or later every engineering team gets the same request: a customer or an auditor wants single sign-on, and the options on the table are SAML and OpenID Connect. They solve the same problem and are not interchangeable, and choosing one often means supporting both later.

This post explains how each protocol works, where each fits, and how to run the two together without doubling your operational load.

What both protocols do

Single sign-on separates the application from the act of authenticating. An identity provider (IdP) signs the user in and tells the application who they are. The application trusts a signed statement from the IdP instead of checking a password itself.

Both protocols have the same three parties under different names.

  • The user, in a browser.
  • The identity provider. Called the IdP in SAML and the OpenID provider in OIDC.
  • The application. Called the service provider (SP) in SAML and the relying party or client in OIDC.

The difference is in the format of the statement and how it travels.

How SAML works

SAML 2.0 is an OASIS standard from 2005. Its statement is an XML document called an assertion, signed with the IdP's private key using XML Signature.

The common flow is SP-initiated with the Web Browser SSO profile:

  1. The user opens the application.
  2. The application redirects the browser to the IdP with an authentication request.
  3. The IdP signs the user in.
  4. The IdP returns an HTML form that the browser posts to the application's assertion consumer service (ACS) URL. The form contains the signed assertion.
  5. The application validates the assertion and creates its own session.

Trust is set up in advance by exchanging metadata: the IdP's entity ID, sign-on URL and signing certificate on one side, and the application's entity ID and ACS URL on the other.

The assertion carries a subject (the NameID), attributes such as email and groups, an audience, and a validity window. Everything travels through the browser.

What a SAML service provider must check

Most SAML vulnerabilities are validation mistakes, so the checklist is worth stating:

  • the signature, against the certificate configured for that IdP, covering the assertion that is actually used
  • the audience matches this application's entity ID
  • the validity window and the recipient URL
  • the assertion ID has not been seen before, to stop replay
  • the response matches a request you sent, unless you deliberately allow IdP-initiated sign-on

Use a maintained library for XML signatures. Do not write your own.

How OIDC works

OpenID Connect is an identity layer on top of OAuth 2.0, published in 2014. Its statement is the ID token, a JSON Web Token signed by the provider.

The recommended flow is the authorisation code flow with PKCE:

  1. The application redirects the browser to the provider's authorisation endpoint.
  2. The provider signs the user in and redirects back with a short-lived code.
  3. The application exchanges the code at the token endpoint, over a direct back-channel request.
  4. It receives an ID token, and usually an access token and a refresh token.

The redirect that starts the flow looks like this:

https://id.example.com/authorize
  ?response_type=code
  &client_id=web-portal
  &redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback
  &scope=openid%20email%20profile
  &state=af0ifjsldkj
  &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
  &code_challenge_method=S256

Configuration is lighter than SAML. A provider publishes a discovery document at /.well-known/openid-configuration and its signing keys at a JWKS URL, so key rotation needs no manual exchange.

The application checks the ID token's signature, issuer (iss), audience (aud), expiry and the nonce it sent.

The differences that matter

  • Format. SAML uses signed XML. OIDC uses signed JSON (JWT). JSON tooling is simpler and more widely available.
  • Transport. SAML delivers the assertion through the browser. OIDC's code flow delivers tokens over a back channel, so they are not exposed to the browser's address bar or history.
  • Client types. SAML was designed for server-side web applications. OIDC works for web, single-page, mobile and command-line clients.
  • API access. SAML tells an application who the user is. OIDC, being built on OAuth, also yields access tokens for calling APIs.
  • Setup and rotation. SAML relies on exchanged metadata and certificates that expire and must be replaced by hand in many products. OIDC relies on discovery and published keys.
  • Installed base. Much enterprise software supports SAML, and for some applications it is the only option.
  • Provisioning. Neither protocol creates or removes accounts ahead of sign-in. That job belongs to SCIM.

When to pick which

Choose OIDC when:

  1. You are building a new application and control both ends.
  2. The client is a single-page app, a mobile app or a CLI.
  3. The same sign-in needs to produce tokens for your APIs.
  4. You want configuration and key rotation to be automatic.

Choose SAML when:

  1. The application you are connecting only supports SAML.
  2. An enterprise customer's IdP team requires it.
  3. You are integrating with an existing federation built on it.

If you sell software to businesses, the realistic answer is to accept both for inbound sign-in. Customers will arrive with whichever their IdP team prefers.

Running both

Supporting two protocols does not have to mean two identity systems. The pattern is to put one identity layer in the middle that speaks each protocol at its edges.

  • One account, one set of groups. Whichever protocol a sign-in arrives on, map it to the same user record. Decide access by group, and let each protocol carry the result in its own format.
  • Normalise claims. SAML attributes and OIDC claims use different names. Define one internal schema and map both to it.
  • Separate signing keys. Use one key for tokens and another for SAML assertions so each can rotate on its own schedule.
  • Track certificate expiry. SAML certificates expiring unnoticed is one of the most common causes of SSO outages.

The split between staff and customer sign-in affects these choices too. See workforce vs customer identity and how to evaluate an identity provider.

How AuthFI does it

AuthFI speaks both protocols and attaches them to one account and one set of groups per person.

For software you bought, AuthFI acts as a SAML 2.0 identity provider. You register the application and copy the sign-on address, entity ID and certificate into it; the metadata and certificate to hand over are on the application's page. See SAML single sign-on.

For your own applications, AuthFI is an OAuth 2.1 and OpenID Connect provider for web, single-page, mobile and machine clients. Every kind of application is registered the same way and is open only to the groups you assign.

For people who already have an account elsewhere, the workforce identity page lists connections to providers such as Okta, Microsoft Entra and Google Workspace over SAML 2.0 and OpenID Connect, with each provider matched to the email domains it answers for. Accounts can be created at first sign-in or ahead of time over SCIM 2.0.

Signing keys are separate per job: one for tokens, verified by any standard OAuth library, and a distinct SAML signer. Public keys are published at /.well-known/jwks.json, and a rotated key stays published for 24 hours so issued tokens keep verifying.

Key takeaways

  • SAML and OIDC both let an application trust a signed statement from an identity provider. SAML's is XML through the browser; OIDC's is a JWT obtained over a back channel.
  • Pick OIDC for new, mobile and API-driven applications. Pick SAML when the other side requires it.
  • If you sell to businesses, expect to accept both.
  • Run both from one identity layer with one user record, one set of groups and separate signing keys.