In this guide 6 sections
Choose OpenID Connect for new products, mobile apps and single page apps, because it uses light JSON tokens and is quicker to build. Choose SAML when a customer’s IT team asks for it by name. Many B2B products end up supporting both, with one shared user model behind them.
What each protocol sends to your app
SAML passes an XML document called an assertion. The identity provider signs it, the browser carries it to your assertion consumer URL, and your app checks the signature against a stored certificate. It is a product of the early enterprise web.
OpenID Connect sits on top of OAuth. It returns an ID token, which is a signed JSON Web Token. Your app reads claims such as sub, email and name. Extra detail comes from a UserInfo endpoint.
The practical gap is parsing. XML signature checks are fiddly, and a badly written validator has been the cause of real login bypass bugs. JWT checks are shorter, though they can still go wrong.
- SAML: XML assertion, signing certificate, assertion consumer URL, entity ID
- OpenID Connect: JWT ID token, client ID, redirect URI, discovery document
- SAML metadata is an XML file you exchange by hand or by URL
- OpenID Connect discovery is one JSON address that lists every endpoint
Browsers, mobile apps and single page apps
SAML was built for a browser that posts a form. A native iPhone or Android app has no such form, so teams open a system browser tab and bounce the result back through a custom URL scheme. It works. It is clumsy.
OpenID Connect was designed for these clients. The authorization code flow with PKCE suits a React single page app, a mobile app and a plain server rendered site. Refresh tokens keep users signed in without a fresh redirect each morning.
If your product has any mobile client, this point alone usually decides it.
What Entra ID, Okta and Google support
Microsoft Entra ID and Okta both speak SAML and OpenID Connect. You register the app once, pick the protocol and copy a few values across. Google Workspace supports both as well, though its SAML app setup lives in the admin console and needs a domain administrator.
Consumer Google sign in is OpenID Connect only. That matters if your product also serves small teams with no identity provider at all.
Check how each provider sends groups. Entra ID can send group object IDs rather than names, and Okta needs a groups claim added by hand. Role mapping fails here more than anywhere else.
- Entra ID: enterprise application, group object IDs, app roles
- Okta: app integration, custom groups claim, attribute statements
- Google Workspace: custom SAML app or OpenID Connect client
- Test with a user who belongs to no groups at all
Setup effort and when IT will insist on SAML
Expect OpenID Connect to take days with a maintained library. SAML takes longer, mostly in certificate rotation, clock skew, signed logout and the many ways a customer can misconfigure their side.
Even so, SAML is often not your choice. A large customer’s security questionnaire may name it. Their identity team may have a template, a policy or a legacy gateway that only handles SAML. Older HR, finance and campus systems also expect it.
Ask early which protocol the buyer needs. Selling to enterprises usually means building SAML second, once the first customer demands it, and keeping the login code behind one interface.
A sensible order of work
Build OpenID Connect first. Keep one internal user record keyed by a stable identifier, never by email alone, because people change names and domains.
Then add SAML as a second connector for the customers who ask. Store each customer’s metadata, certificate expiry date and attribute mapping on their own record. Add a screen where their administrator can paste metadata and test the link.
This week, list your five biggest customers and write down which protocol their identity provider supports and who owns it.
- One user table, many sign in methods
- Per customer: protocol, metadata, certificate expiry, group mapping
- A test login page for customer administrators
- Logout and session length agreed with each customer
SSO protocol decision sheet
Decision sheet in three parts. Part one lists your client types: web, iOS, Android, desktop and API. Part two gives each customer a row, with columns for identity provider, required protocol, group claim name and certificate expiry. Part three is a go or no-go list for logout, session length and role mapping.
Open a blank worksheet to printQuestions owners ask
Is OpenID Connect more secure than SAML?
Neither is weaker by design. Both rely on signed tokens and correct validation. Most real failures come from sloppy checks of the signature, audience or expiry, so use a maintained library for either one.
Can one product support both protocols?
Yes. Treat each as a connector that ends in the same internal user and role. The login screen asks for the company domain, then sends the person to the right identity provider.
Do we need OAuth as well?
OpenID Connect is a layer on OAuth, so you get it already. You need plain OAuth when your app calls another service for the user, such as reading a calendar.
What breaks most often after launch?
An expired signing certificate on the customer’s side. Record the expiry date, warn their administrator well ahead, and let two certificates work together during the swap.