SSO vs OAuth: one is a login experience, the other is an access grant

SSO (single sign-on) is a user experience: sign in once, and get into many applications without signing in again. OAuth 2.0 is a protocol for granting an application limited access to a resource on the user's behalf.

They are not alternatives. SSO is an outcome you design; OAuth is one of several mechanisms you can use to get there — and on its own, OAuth is not even a login protocol. This article explains the difference and where OIDC and SAML fit.

What SSO means

SSO is about sessions. A user authenticates once at a central identity provider, and each application accepts that authentication instead of showing its own login form. The user experience:

1. Open application A. Redirected to the identity provider. Sign in.
2. Open application B. Not asked again — the identity provider still has a session.
3. Sign out centrally, and every application's session ends.

How the applications trust the identity provider is an implementation detail: SAML assertions, OIDC ID tokens, CAS tickets, or a shared cookie on a common domain all produce SSO.

What OAuth means

OAuth 2.0 (RFC 6749) lets a user delegate access to their resources without sharing a password. An application obtains an access token with specific scopes, and uses it to call an API.

• The token says "this application may read this user's calendars for the next hour".
• It does not say "this user is who they claim to be" — that is not what OAuth was designed for.

OAuth is what powers "connect your Google Calendar", "authorize this CLI against GitHub", and most of the API integrations in your browser. The token is the point.

Where OIDC fits

Because developers kept using OAuth to log users in, the industry standardized the missing piece: OpenID Connect adds an identity layer on top of OAuth 2.0. It introduces the ID token (a signed statement about the user) and standardizes the userinfo endpoint and discovery.

So:

• OAuth 2.0 = authorization for APIs.
• OIDC = authentication built on OAuth 2.0.
• SSO = one session across applications, which OIDC can provide.

A "sign in with Google" button is OIDC. A "let this app read my Google Drive" grant is OAuth.

Side by side

Two common mistakes

Mistake 1: "We use OAuth, so we have SSO." If each application runs its own OAuth client and its own session, users still sign in to each application; you have delegated access, not single sign-on. SSO requires a shared identity provider that maintains the session.

Mistake 2: "SSO means one password." SSO does not remove passwords by itself. It centralizes authentication, which makes it a natural place to add MFA and passkeys — but a deployment with one password and no MFA is still a deployment with one password and no MFA.

How the pieces fit in practice

A typical setup:

• The identity provider holds users and sessions, and speaks OIDC and SAML to applications.
• Applications are service providers: they redirect to the identity provider and accept its tokens or assertions.
• APIs are protected with OAuth access tokens, often issued by the same identity provider.
• Machine-to-machine calls use the OAuth client credentials flow, which involves no user and no SSO.

Casdoor plays the identity provider role for all three: OIDC and SAML for browser SSO, OAuth tokens for APIs, and CAS for legacy applications. See what single sign-on is, OAuth vs OIDC and SAML vs OIDC.

Casdoor is open source and self-hostable, with a hosted option from $9 per month and no per-user fees.