OAuth vs OpenID Connect vs SAML: what each one is for

Short answer: OAuth 2.0 is about authorisation: letting an app act on your behalf without your password. OpenID Connect (OIDC) is a thin layer on top of OAuth that adds authentication, so an app learns who you are. SAML is an older XML-based standard for enterprise single sign-on. For a new product use OIDC for sign-in, and add SAML when an enterprise customer asks for it.

What does OAuth 2.0 do?

It lets a user grant an application limited access to something held by another service, without sharing credentials. When a scheduling app asks to read your calendar, you approve it on the calendar provider's page, and the app receives an access token with a defined scope. OAuth by itself does not tell the app who you are. An access token is meant to be used against an API, not to prove identity.

The main flow for web apps is the authorization code flow with PKCE: the app sends the user to the provider, the user logs in and consents, the provider redirects back with a one-time code, and the app exchanges the code for tokens on the back channel. PKCE protects the code from interception and is recommended for all clients, including server-side apps.

What does OIDC add?

An ID token, which is a signed JWT containing claims about the authentication event and the user: a stable subject ID (sub), issuer, audience, expiry and optionally email and name. There is also a standard userinfo endpoint and a discovery document at /.well-known/openid-configuration. This is what "Sign in with Google" is.

GET /authorize?
  response_type=code
  &client_id=YOUR_ID
  &redirect_uri=https://app.example.com/callback
  &scope=openid email profile
  &state=RANDOM
  &code_challenge=...&code_challenge_method=S256

The openid scope is what turns an OAuth request into an OIDC request.

What is SAML?

Security Assertion Markup Language, from the early 2000s. A company's identity provider (such as Okta or Entra ID) sends an XML assertion about the user to a service provider (your app), signed with a certificate. It is widely used in large organisations to give staff one login across many tools, and it is what enterprise buyers mean by "we need SSO".

How do they compare?

• Purpose: OAuth, delegated access. OIDC, login. SAML, enterprise SSO.
• Format: OAuth and OIDC use JSON and JWT over HTTP. SAML uses XML.
• Best for: OIDC suits web, mobile and single-page apps. SAML suits browser-based enterprise apps.
• Complexity: SAML has more moving parts: XML signatures, certificate rotation, metadata exchange. XML signature handling has a history of vulnerabilities, so use a maintained library and never hand-roll it.

Common mistakes

• Using an OAuth access token as proof of login. Use the OIDC ID token, and validate signature, iss, aud, exp and nonce.
• Skipping the state parameter, which protects against CSRF on the callback.
• Not using exact redirect URI matching.
• Using the implicit flow. It is deprecated. Use authorization code with PKCE.
• Treating the email claim as a stable identifier. Use sub combined with iss, since emails change and can be reused.
• Accepting unverified emails when linking accounts, which enables account takeover.

What should you build?

• A new app with consumer logins: OIDC with a provider like Google or Microsoft, plus email login if you need it.
• You want logins without running the infrastructure: a hosted identity service or an open-source identity server, instead of writing it yourself.
• B2B product: start with OIDC, and add SAML when a customer requires it. Many teams use a library or service that does both and charge for SAML as an enterprise feature.
• Calling someone else's API on a user's behalf: OAuth 2.0 scopes.

After login you still need a session or token for your own app. That choice is covered in JWT vs session cookies.