SSO vs OAuth 2.0: Core Differences, CAS Flow, and Four Grant Types Explained

Overview

SSO (Single Sign On) and OAuth (Open Authority) both use tokens instead of user passwords to access applications. Their flows appear similar but their concepts differ fundamentally. SSO separates authentication from business systems via a central login center, enabling access to all linked systems after one login. OAuth 2.0 authorizes third-party applications to access user resources on another server — commonly seen when a site offers "Login with WeChat" instead of local registration.

SSO and the CAS Flow

SSO is an architectural idea; CAS is one framework implementing it. The CAS flow works as follows:

User accesses a protected application ( Protected App). The app detects no login and redirects to the CAS Server with a service parameter (its own URL).

Browser reaches CAS Server. CAS checks for an existing global session. If absent, it shows its own login page; if present, it sets a global session and redirects back to the app with a CAS-issued ticket.

User submits credentials on the CAS login page (only CAS stores passwords).

CAS validates credentials. On success, it redirects to the app with the ticket.

App receives the ticket at its login endpoint (no password needed). It calls CAS to validate the ticket and retrieve user info, then creates a local session ( sessionId, e.g., Tomcat's JSESSIONID) and returns it to the browser.

Subsequent requests use the local sessionId.

A familiar example: opening the Taobao app shows links to Tmall and Juhuasuan; clicking them jumps directly without re-login.

OAuth 2.0 and Its Four Grant Types

OAuth 2.0 defines roles: Authorization Server, Resource Server, Client. For SSO-like use, only Authorization Server and Client are needed. The flow (Authorization Code grant) mirrors SSO:

User clicks "Login with WeChat" on a site (Client). Site redirects to WeChat Authorization Server.

WeChat shows a consent page (its own UI, not the site's).

User approves. WeChat validates and returns an authorization code (ticket), redirecting back to the site.

Site exchanges the code for an access_token at WeChat's token endpoint, then uses the token to fetch user info.

Four Grant Types (RFC 6749)

Authorization Code (authorization-code)

Most common and secure. Client obtains an authorization code via front-end redirect, then exchanges it for a token on the back-end. Token stays on the server; all resource-server calls happen server-side. Front-back separation prevents token leakage. Suits traditional web apps with backends.

Implicit (implicit)

For pure front-end apps (no backend). Token is issued directly to the front-end (e.g., in URL fragment). No intermediate code step. Less secure because token is exposed in the browser.

Resource Owner Password Credentials (password)

User gives username/password directly to a highly trusted client. Client uses them to request a token. Only for first-party or fully trusted apps; not for third-party.

Client Credentials (client-credentials)

For machine-to-machine or CLI tools with no user context. Client authenticates with its own client_id / client_secret to obtain a token.

Terminology Distinctions

SSO — an abstract solution/architecture pattern. Implementations follow its idea (e.g., CAS, or OAuth 2.0 adapted for SSO).

OAuth 2.0 — a protocol for delegated authorization (third-party access to user resources). Not designed for SSO, but can be leveraged to achieve it. In that case, the protected resource is user identity/permissions; tokens are often JWTs carrying Access_Token.

Spring Security / Shiro — Java security frameworks for access control (authentication + authorization) within an application. They enforce permissions but are not SSO or OAuth protocols themselves.