Single Sign-On vs OAuth vs SAML: Identity and Access Explained

Single sign-on (SSO) is the result: people sign in once and reach many applications. SAML and OpenID Connect are the protocols that usually deliver it, by letting an identity provider such as Microsoft Entra ID vouch for a user to each application. OAuth 2.0 does a different job: it is an authorization framework that lets an application get limited access to another service on a user's behalf, and OpenID Connect adds the sign-in layer on top of it.

Our single sign-on service connects business applications to Entra ID through SAML or OpenID Connect. For the business case, what SSO does for a small company and whether it is worth it, see single sign-on for small business; this post explains the protocols underneath.

What is the difference between SSO, OAuth and SAML?

They sit at different layers. SSO is an outcome, SAML and OpenID Connect are ways to prove who a user is to an application, and OAuth 2.0 is a way to grant an application permission to act. Each one answers its own question:

Is single sign-on a protocol?

No. SSO is the experience, and several mechanisms can produce it. Microsoft Learn describes SSO as signing in with one set of credentials and then opening every assigned application without signing in again; when Entra ID is the identity provider, it verifies the user and confirms that identity to each app, so the apps stop managing their own usernames and passwords.

Entra ID offers federation-based SSO through SAML 2.0 or OpenID Connect, password-based SSO that stores credentials and replays them for apps that cannot federate, and linked SSO, which puts an app's link in the user portal but, as Microsoft notes, is not true single sign-on. So SSO vs SAML is not really a choice: SAML is one of the ways to deliver SSO.

How does SAML work?

The OASIS SAML 2.0 technical overview describes SAML as an XML-based framework for exchanging security information between online business partners, carried in assertions that applications in different security domains can trust. In web SSO, the identity provider authenticates the user and sends an assertion to the service provider, which is the application.

There are two common flows. In the more common one, SP-initiated, the user opens the application, the application sends them to the identity provider to sign in, and the identity provider returns an assertion the application uses to grant access. In IdP-initiated SSO, the user starts at the identity provider, for example a portal of company apps, and clicks through. SAML 2.0 supports both.

How does OAuth 2.0 work, and why isn't it a sign-in protocol?

RFC 6749 defines OAuth 2.0 as a framework that lets a third-party application obtain limited access to a web service. Instead of handing the application your password, you approve the access with an authorization server, which issues the application an access token: a string that represents a specific scope, lifetime and other access attributes. The RFC's own example is a printing service that gets access to your photos on a photo-sharing site without ever seeing your password.

An access token says what an application may do. OAuth on its own does not define a standard way to tell the application who you are, which is the gap OpenID Connect fills. OpenID Connect Core 1.0 calls itself a simple identity layer on top of OAuth 2.0: it lets the application verify the user's identity based on the authentication the authorization server performed, and returns an ID token, a JSON Web Token carrying claims about that sign-in.

Single sign-on vs OAuth: when do you use each?

For a business, the split is simple: SSO is how your people get into applications, and OAuth is how applications get into your data.

• Staff signing in to the CRM, payroll or accounting system: SSO through SAML or OpenID Connect, with Entra ID as the identity provider.
• A scheduling or e-signature app that needs to read calendars or mailboxes: OAuth 2.0. The app asks for permission, and a user or administrator consents to a defined scope.
• Your own developers building an app that signs users in and calls APIs: OpenID Connect for the sign-in, OAuth 2.0 for the API access.
• An older app that supports neither: password-based SSO or a business password manager, so the app is still covered when someone leaves.

OAuth consent is also an attack path. A malicious app can ask users to grant it access to mail or files, and the request looks legitimate because the consent screen is real. Our post on OAuth consent phishing in Microsoft 365 explains how to restrict who can approve those requests.

What does current security guidance say about OAuth?

The IETF's RFC 9700, the Best Current Practice for OAuth 2.0 Security published in January 2025, updates the original framework. It says clients should not use the implicit grant, which returns tokens directly in the browser redirect, and should use the authorization code grant instead; that the resource owner password credentials grant, in which the app collects the user's password, must not be used; and that public clients, such as mobile and single-page apps, must use PKCE.

You do not need to read the RFC to use that guidance. If a vendor's integration asks for a user's password to connect to Microsoft 365 or another service, rather than sending you through a consent screen, ask the vendor why before you approve it.

Which fits a small team: SAML, OpenID Connect or OAuth?

A small team does not pick a protocol so much as an identity provider. If you run Microsoft 365, that is usually Entra ID, which you already pay for. Then each application is connected with whatever it supports:

1. OpenID Connect or SAML for sign-in. Microsoft's guidance is that OpenID Connect is usually simpler with modern frameworks and SAML offers broader enterprise compatibility; for an off-the-shelf app, use what the vendor documents.
2. Automatic provisioning through SCIM where the app offers it, so accounts are created and removed with the user's identity.
3. A password manager for apps that cannot federate.
4. MFA and Conditional Access at the identity provider, so every connected app inherits them.
5. A periodic review of OAuth app consents, removing grants for apps nobody uses and any you do not recognize.

What drives the cost and effort of single sign-on?

The protocols are free standards; the work is in the integration. What moves it:

• The number of applications and how many support SAML or OpenID Connect.
• Vendor plans. Some applications charge extra for SSO on their side, which only an inventory turns up.
• Licensing. Entra ID comes with Microsoft 365, and Microsoft says Business Premium customers can use Conditional Access, the policy engine that makes SSO worth doing. Risk-based sign-in policies need Entra ID P2, which Business Premium does not include; Microsoft's Defender Suite for Business Premium adds it.
• Provisioning. Apps with SCIM save manual account work; apps without it need a checklist.
• Testing and change. Connecting apps a few at a time with a pilot group, then rewriting the offboarding procedure.

For our managed clients, SSO implementation and ongoing management are included in the monthly agreement. Businesses with internal IT can engage the rollout as a fixed-scope project, quoted after the application inventory.

How does NetSys help with SSO, SAML and OAuth?

We start with an application inventory built from Entra ID sign-in logs, expense records and a short staff survey, because the apps IT does not know about are the risk. Each app is sorted: federate through SAML or OpenID Connect, provision with SCIM where available, vault in a business password manager, or retire. We connect apps a few at a time with a pilot group, set Conditional Access at the tenant level, and enforce phishing-resistant MFA, such as passkeys or Windows Hello for Business, at the Entra ID sign-in.

Offboarding becomes one action: disabling the Entra ID account revokes Microsoft 365 and every federated app, and active sessions are ended. We test that with a real departure, run a quarterly access review, and our agreements run month to month.

Book a call with a NetSys engineer to list the applications your team uses and find out which can move to single sign-on first.

Frequently asked questions

What is the difference between single sign-on and OAuth?

Single sign-on lets a person sign in once and reach many applications, usually through SAML or OpenID Connect. OAuth 2.0 lets an application obtain limited access to another service on a user's behalf, using an access token with a defined scope. SSO is about people getting into apps; OAuth is about apps getting into data.

Is SAML the same as SSO?

No. SAML is a protocol and SSO is the outcome. SAML 2.0 is one of the standard ways to deliver SSO, alongside OpenID Connect; password-based SSO is another option for applications that support neither.

Which fits a small team?

The identity provider you already have, usually Entra ID with Microsoft 365, connected to each app by SAML or OpenID Connect, plus a password manager for the rest. Turn on MFA and Conditional Access at the identity provider so every app inherits them.

What affects the cost, implementation and support?

The number of applications, which protocols they support, vendors that charge extra for SSO, provisioning, licensing and testing. Ongoing support covers adding new apps, access reviews and the offboarding process.

Is OAuth an authentication protocol?

Not by itself. RFC 6749 defines OAuth 2.0 as an authorization framework. OpenID Connect adds authentication on top of OAuth 2.0, returning an ID token that tells the application who signed in.

Should we use SAML or OpenID Connect?

Use whichever the application supports and documents. When both are offered, Microsoft notes that OpenID Connect is usually simpler with modern frameworks while SAML has broader enterprise compatibility, and both work with Entra ID.