What is single sign-on, and why do both SAML and OIDC exist?

Single sign-on (SSO) means a person proves who they are once, to one trusted system, and every connected application accepts that proof instead of asking for its own password. The trusted system is the identity provider (IdP).

Each application is a service provider (SP), or in OpenID Connect language, a relying party.

That is the whole idea. The interesting part is how the proof travels from the IdP to the application, and that is where SAML and OpenID Connect (OIDC) come in.

The problem SSO removes

Without SSO, every application keeps its own list of users and passwords. Consequences for an IT team:

• A leaver must be removed from every list separately, and someone will be missed.
• Password resets become a large share of help-desk work.
• People reuse passwords across apps because they cannot remember thirty of them.
• Multi-factor authentication is applied unevenly, because each app implements it differently or not at all.
• Nobody can answer "who signed in to what, and when?" from one place.

With SSO, the IdP is the single place where you enforce MFA, end sessions and disable accounts. Applications stop being responsible for credentials.

What actually happens during a login

Whichever protocol is used, the flow has the same shape:

1. The user opens an application and is not signed in.
2. The application redirects the browser to the IdP, saying who is asking.
3. The IdP authenticates the user (password, passkey, MFA) or recognises an existing session.
4. The IdP redirects the browser back to the application with a signed assertion about the user.
5. The application verifies the signature, reads the claims, and creates its own local session.

The signature in step 5 is the point. The application never sees the user's password. It trusts the IdP's cryptographic statement.

SAML 2.0: the older, XML-based standard

SAML 2.0 is an OASIS standard from 2005. The IdP sends a signed XML document called an assertion, usually through the user's browser using an HTTP POST.

The assertion carries a subject identifier, attributes such as email and group, a validity window and an audience.

SAML is common in enterprise software built over the last two decades, which is why many established business applications support it and only it.

Setup is done by exchanging metadata: the application gives you an entity ID and an assertion consumer service (ACS) URL; the IdP gives back its own entity ID, sign-on URL and signing certificate.

Practical notes for SAML:

• Certificates expire. Put the signing certificate expiry date in a calendar, or an SSO outage will arrive as a surprise.
• Clock skew matters. Assertions have a validity window of minutes, so unsynchronised servers fail in confusing ways.
• The NameID format must match what the application expects. "Email address" versus "persistent identifier" is a frequent cause of duplicate accounts.
• Sign the assertion, and have the application validate audience and recipient, not only the signature.

OpenID Connect: the newer, JSON-based layer

OIDC arrived later and is built on OAuth 2.0 (RFC 6749). OAuth was designed for delegated authorisation: letting an application call an API on a user's behalf. It was not designed to say who the user is.

OIDC Core 1.0 adds that missing piece: an ID token, which is a JSON Web Token (RFC 7519) signed by the IdP, plus a standard UserInfo endpoint and discovery document.

For browser and mobile apps, the recommended flow today is authorization code with PKCE (RFC 7636), described in more detail in Implementing OIDC with PKCE.

Keys are published as a JWK set (RFC 7517), so applications can rotate trust without anyone emailing certificates.

OIDC fits modern single-page apps, mobile apps and APIs well, because JSON and plain HTTPS are easy to work with and there is no XML signature canonicalisation to get wrong.

Why both still exist

They are not competing in practice. They reflect when software was built and who built it.

Vendors rarely rewrite working SAML integrations just because a newer protocol exists, and newer products often skip SAML entirely. The practical consequence is simple: an identity platform that wants to cover your application portfolio has to speak both.

How to choose per application

You usually do not get to choose; you read the application's SSO documentation and use what it supports. When an application offers both:

• Prefer OIDC for anything new, especially if it includes a mobile or single-page front end.
• Prefer SAML if the application's SAML support is mature and your team already operates it well.
• Avoid the temptation to run both for one application "just in case". Two paths means two sets of attributes to keep consistent.

What SSO does not do

SSO is often described as a security feature on its own. It is more accurate to say it concentrates your controls. If the IdP login is weak, every app is weak.

So pair SSO with strong authentication, ideally phishing-resistant factors (see Passkeys explained), and with session control so you can end access quickly.

SSO also does not create or remove accounts inside applications.

A person who is disabled at the IdP cannot sign in through SSO, but the account may still exist in the app, and any local password, API token or long-lived session may still work.

That is the gap that SCIM provisioning closes; see SCIM 2.0 in plain English.

Where AuthMantra fits

AuthMantra supports both SAML 2.0 and OpenID Connect (authorization code with PKCE), with pre-built connectors for common SaaS applications, so one identity provider can cover applications on either protocol. See single sign-on for every app for the details.

What to do this week

1. List your ten most-used applications and note which SSO protocol each supports. Write "none" honestly where that is the answer.
2. For each SAML application, record the signing certificate expiry date and who owns renewal.
3. Check which applications still allow local passwords for users who also sign in via SSO, and decide whether to disable that.
4. Confirm that disabling a user at the IdP also ends their active sessions in your most sensitive application.
5. Look up the glossary entries for SAML and OIDC so your whole team uses the same words.