Architecture
Single Sign-On Explained: SAML, OAuth, and OpenID Connect
Updated January 18, 2022By the CalliArc team
Key takeaway
OAuth 2.0 is authorization — granting access to resources. OpenID Connect adds authentication on top of it and is the modern default for new integrations. SAML is older and still what most enterprise identity providers expect, so a product selling to enterprises usually has to support both.
These three names get used interchangeably in requirements documents, and they do different jobs. Getting them straight saves a great deal of confusion in the security review that sells your product.
What each one is
- OAuth 2.0 — an authorization framework. It lets an application act on a user's behalf against an API without holding their password. It does not, by itself, tell you who the user is.
- OpenID Connect — an authentication layer on OAuth 2.0. It adds an ID token that identifies the user. This is what you want for "log in with…".
- SAML 2.0 — an older XML-based standard for exchanging authentication and attributes between an identity provider and an application. Ubiquitous in enterprise IT.
Which to implement
- Consumer or developer-facing login: OpenID Connect.
- Third-party API access on a user's behalf: OAuth 2.0 with appropriately scoped tokens.
- Enterprise customers with an existing identity provider: expect to support SAML, and increasingly OIDC alongside it.
- Service-to-service: client credentials, or short-lived workload identity — not a user flow.
What enterprise SSO really involves
- Per-tenant identity provider configuration, with self-service setup if you don't want a support ticket per customer.
- Just-in-time provisioning — creating the user on first successful login, with role mapping from the assertion.
- Deprovisioning, which SSO alone doesn't give you. SCIM is what actually removes access when someone leaves.
- Group-to-role mapping, because enterprises will expect their directory groups to drive permissions in your product.
- A break-glass path for when the identity provider is down or misconfigured.
Implementation cautions
- Use a well-maintained library. Validating signatures and assertions correctly is subtle, and mistakes here are authentication bypasses.
- Validate the audience, issuer, expiry, and — for OIDC — the nonce on every token. Skipping any of these has produced real vulnerabilities.
- Use the authorization code flow with PKCE for anything browser- or mobile-based; the implicit flow is obsolete.
- Treat certificate and key rotation as a scheduled task; an expired SAML certificate locks out an entire customer without warning.