SAML vs OpenID Connect: Which SSO Protocol Should Your App Use?

Single sign-on means the user authenticates with a central identity provider, and your app trusts that result. Okta's SSO overview describes the two federated protocols it supports for that job: OpenID Connect and SAML 2.0. For new integrations, Okta recommends OpenID Connect. The protocol you pick changes the libraries, the onboarding steps for each customer, and which apps you can cover. It does not replace the rest of your product's login design.

What each protocol actually is

SAML 2.0 is XML. Microsoft Entra's decision guide describes it as a mature federation protocol: the identity provider sends signed XML assertions that carry sign-in data and attributes. The browser usually posts that assertion to your app (the service provider). Your app checks the signature and then creates a session. Enterprise directories have used this pattern for browser apps for years. Microsoft notes that mobile and single-page support is the harder side of SAML, and that customer setup is often manual.

OpenID Connect sits on OAuth 2.0. The OpenID Foundation defines it as a way to verify identity and fetch profile claims in a REST-like flow. The provider returns an identity token — a signed JWT with at least a subject claim — and usually an access token. The app can then call a UserInfo endpoint with that access token. OAuth 2.0 is what grants access to APIs. OpenID Connect is what answers "who is this user?" The same page says OpenID Connect was built for web, JavaScript, and native clients, and that SAML was designed for web-based applications. The two are expected to coexist.

Which one to ship

Microsoft's summary matches that table: default to OpenID Connect for new SaaS, choose SAML when enterprise customers, a legacy provider, or a mandate requires it, and support both when the customer base spans both. Both protocols can be implemented securely. The difference is fit, not a claim that one is "more secure" in the abstract.

What SSO does not decide

After the identity provider says the user is real, your app still has to keep them signed in, authorize what they can do, and sign them out.

• Session shape. An OIDC ID token is a JWT. That does not mean your app must be stateless. You can validate the token once and issue your own server session. A SAML assertion is XML; apps almost always turn it into their own session. How to choose JWT versus server sessions for that second step is a separate question, covered in JWT vs session authentication.
• Authorization. SSO proves identity and can pass group or role claims. Your ERP or CRM still decides which screens and records those claims unlock. Do not treat "the assertion included a department" as a full permission model.
• Logout. Okta notes that single logout depends on each app's protocol support, so sign-out can be inconsistent unless you design it. Decide whether "log out" kills only your app session or must also end the identity-provider session. Write that down before you promise it in a security review.
• Account linking. The first SSO login has to map the identity-provider subject to a user in your database. Plan the link, the invite, and what happens when the same email arrives from two providers.

A build order that avoids two half-finished stacks

1. Pick the identity providers your first customers actually use. If they all speak OpenID Connect, do not start with SAML.
2. Implement one protocol on one app, including signature checks, issuer and audience checks, and a mapped user.
3. Pass only the attributes you need (email, name, groups). Extra claims become data you must store and explain.
4. Add the second protocol when a real customer cannot connect with the first. Microsoft calls that the mixed-environment case, not the day-one default.
5. For a product many companies log into, tenant-specific identity settings belong with the rest of the tenant model. See multi-tenant vs single-tenant SaaS for that boundary.

How long this takes depends on the number of providers, whether logout and attribute mapping are in scope, and whether you are bolting SSO onto an app that already stores its own passwords. That scope is set during discovery, not by a fixed timeline.

Custom ERP, CRM, and internal platforms are where this shows up in practice: the software is yours, and the identity system is the customer's. That work sits with custom software development.