SSO, SAML, OAuth and OIDC explained

Single sign-on (SSO) is the outcome: sign in once, reach many applications. SAML and OpenID Connect (OIDC) are the protocols that deliver it by proving who the user is. OAuth 2.0 is different: it grants an application limited access to something, such as an API, and says nothing on its own about who signed in. The decision rule for the exam: “who is this user” means SAML or OIDC; “let this app act on the user’s data” means OAuth; and OIDC is OAuth with an identity layer added on top.

The four terms and the one job each does

Term	Job	Carries	Typical use
SSO	Outcome, not a protocol	Nothing; it is a user experience	One sign-in for many apps
SAML 2.0	Authentication (federation)	A signed XML assertion about the user	Enterprise web apps, older SaaS
OAuth 2.0	Authorization (delegated access)	An access token with scopes	An app calling an API for a user
OpenID Connect	Authentication on top of OAuth	An ID token (a JWT) plus the OAuth access token	Modern web, mobile and single-page apps

Two names recur in every protocol. The identity provider (IdP) authenticates the user and vouches for them; Microsoft Entra ID is one. The service provider (SP) is the application that trusts the IdP. In OAuth the same roles are called the authorization server and the client, and the API holding the data is the resource server.

SAML 2.0 is an XML standard from OASIS. The application never sees the password.

The user opens the application (the SP).
The SP redirects the browser to the IdP with an authentication request.
The IdP authenticates the user, including MFA if policy requires it.
The IdP returns a signed assertion to the SP through the browser. It states who the user is and can include attributes such as email and group membership.
The SP verifies the signature against the certificate it trusts from the IdP and creates a session.

The trust is configured in advance by exchanging metadata: the SP knows the IdP’s sign-in URL and signing certificate, and the IdP knows the SP’s identifier and the URL that receives assertions. That is why SAML is described as a federation: two parties with a prearranged trust. An expired signing certificate is a classic cause of SAML sign-in suddenly failing for every user.

How OAuth 2.0 and OIDC differ in what they return

OAuth 2.0 (RFC 6749) was written so that a user can let one application use their data in another without giving away the password. The result is an access token with scopes, which limit what the app may do. The access token is meant for the API. The client application should not treat it as proof of who the user is.

OIDC fixes that by adding one thing: when the client asks for the openid scope, the authorization server also returns an ID token, a signed JWT that says who authenticated and when. OIDC uses JSON tokens and fits mobile apps, single-page apps and APIs better than SAML, whose XML assertions are built for browser-based web sign-in.

For public clients such as mobile apps and single-page applications, the authorization code flow is used with PKCE (RFC 7636), which stops a stolen authorization code from being redeemed by someone else. The older implicit flow, which returned tokens straight in the redirect, is no longer recommended (the OAuth 2.0 Security Best Current Practice, RFC 9700, advises against it).

A worked example: the same company, three requests

Contoso uses Entra ID as its IdP.

Payroll SaaS. The vendor supports SAML. HR staff click the app in their portal, Entra sends a signed assertion, and they land in the app already signed in. This is SAML SSO. In Entra it is configured as an enterprise application.
A custom mobile app. The developers need to know who the user is and also call an internal API for them. They use OIDC with the authorization code flow and PKCE: the ID token tells the app who signed in, and the access token gets the API call through.
A calendar-sync tool. A third-party tool asks for permission to read users’ calendars. The user sees a consent screen listing scopes and approves. This is OAuth at its core: delegated access to an API, which works without the tool needing to know who the user is.

An old on-premises application that supports neither protocol can still get Entra SSO through password-based SSO, where Entra stores the credentials and replays them, typically via Application Proxy. Linked SSO only adds a shortcut to the app in the portal and is not real single sign-on. Microsoft documents both on its page about single sign-on in Entra.

Which exams test this

Exam	How it appears	Where it is covered here
SY0-801	Security Operations, identity and access management objective (4.5): federation, and SSO through SAML, LDAP and OAuth; V8 launches November 17, 2026	Security operations explained
SC-300	User identities: external identity providers over SAML and WS-Fed, seamless SSO; workload identities: SaaS app integration, app authentication, user and admin consent, policies for OAuth apps	Workload identities, User identities
SC-900	Concepts of security, compliance, and identity: define authentication and authorization, describe identity providers and federation	Security, compliance and identity concepts
AZ-400	Develop a security and compliance plan: secretless authentication with workload identity federation and OpenID Connect in GitHub Actions and Azure Pipelines	Security and compliance
SC-500	Manage identity, access, and governance: manage OAuth permission grants and consent settings	Identity, access and governance
AZ-900	Minor: Azure identity, access, and security lists SSO among the authentication methods to describe; protocols are not named	Architecture and services
AB-900	Minor: core security features of Microsoft 365 include the purpose and benefits of SSO; protocols are not named	Microsoft 365 core features
N10-009	Minor: Network Security (4.1) lists SSO and SAML among IAM authentication options	N10-009 network security explained

How exam questions are built around it

The standard trap is mixing authentication with authorization. “OAuth is used to authenticate users” is the wrong answer in a surprising number of questions; OAuth authorizes, and OIDC is the protocol that authenticates on top of it. Read the verb in the scenario: “sign in”, “verify identity” and “single sign-on” point to SAML or OIDC; “access the user’s files”, “call an API on behalf of” and “grant permission” point to OAuth.

The second split is SAML versus OIDC. Constraint words that favour SAML: “legacy”, “enterprise”, “XML”, “assertion”, “the vendor only supports SAML”. Words that favour OIDC: “mobile app”, “single-page application”, “JSON”, “REST API”, “JWT”. When the question names a pipeline that must deploy to a cloud with no stored secret, the answer is OIDC federation, not a client secret and not SAML.

Third, watch for the word “federation” in a question about two organisations. It means a trust between identity providers so that one organisation’s users sign in to the other’s resources without a second account. And “consent” in a security scenario usually points at OAuth: users approving broad scopes for a risky app is a governance problem, solved by restricting user consent or reviewing grants, not by changing the sign-in protocol.

Practice questions

Question 1. A software vendor offers a web application that supports only SAML 2.0 for single sign-on. Contoso wants its employees to reach the application with their Entra ID credentials and no separate password. What does Entra ID send to the application after the user authenticates?

A. The user’s password, encrypted with the application’s public key
B. An OAuth 2.0 access token with the openid scope
C. A signed SAML assertion containing the user’s identity and attributes
D. An OpenID Connect ID token in the URL fragment

Show answer

Answer: C

In SAML the identity provider returns a signed assertion about the user to the service provider through the browser, and the application validates the signature against the IdP certificate. An OAuth access token is meant for calling an API, not for a SAML sign-in. An ID token belongs to OpenID Connect. Entra does not forward the password; that would defeat the purpose of federation.

Question 2. A mobile app must show the signed-in user's name and also call a company REST API on that user's behalf. The developers want a standards-based approach that avoids SAML. Which protocol combination fits?

A. OAuth 2.0 only, using the access token to read the user’s name
B. OpenID Connect on top of OAuth 2.0, using the authorization code flow with PKCE
C. SAML 2.0 with a signed assertion sent to the API
D. LDAP bind with the user’s credentials from the mobile app

Show answer

Answer: B

OpenID Connect authenticates the user and returns an ID token, and because it is built on OAuth 2.0 the same flow also issues an access token for the API. OAuth 2.0 alone gives an access token but no standard way to learn who the user is. SAML is XML-based and is the option the scenario excludes. LDAP is a directory protocol and does not provide token-based API access.