Understanding SSO vs OAuth2.0: Concepts, Flow, and Key Differences

Overview

SSO (Single Sign‑On) and OAuth (Open Authorization) both use tokens instead of passwords to access applications, but they differ in concept: SSO separates authentication from business systems via a central login center, while OAuth authorizes third‑party access to resources.

SSO

SSO is a design philosophy; frameworks like CAS implement it. The typical SSO flow:

User accesses a protected application ( Protected App) and is redirected to the CAS server with a service parameter.

The CAS server checks if the user is already logged in; if not, it redirects to the login page, otherwise it creates a global session and redirects back.

User submits credentials on the SSO login page; only the SSO system stores the password.

CAS validates the password, issues a ticket, and redirects to the business system.

The business system receives the ticket, validates it with CAS, creates a local session ( sessionId / JSESSIONID), and returns it to the browser.

Subsequent interactions use the sessionId for authentication.

Example: opening a link in the Taobao app jumps directly to related services without another login.

OAuth2.0

OAuth2.0 provides several grant types; the article focuses on the Authorization Code flow, which resembles SSO but involves an authorization server, resource server, and client. In an SSO‑like scenario only the authorization server and client are needed.

The authorization server handles authentication; the client (application) receives user info and permissions after successful login.

User clicks “Login with WeChat” on a website (client).

WeChat’s authorization server presents its own login page.

User authenticates, and WeChat returns a ticket to the client.

The client exchanges the ticket for an access token, which it uses to fetch user information.

OAuth2.0 Grant Types

Authorization Code : Most secure, suitable for server‑side web apps; the client obtains a code then exchanges it for a token.

Implicit : Designed for pure front‑end apps; the token is returned directly to the browser without a code.

Password : Trusted applications can request a token by sending the user’s username and password.

Client Credentials : Used by command‑line or service‑to‑service apps without a user context.

A simple diagram of the OAuth2.0 flow is included in the original article.

Key Terminology Differences

SSO is an abstract solution concept; implementations vary.

OAuth2 is a protocol for delegating access, not originally intended for SSO, but it can be used to achieve SSO by treating the protected resource as user information and using JWT as the access token.

Spring Security and Shiro are Java frameworks that provide security and access‑control features for both SSO and OAuth2 implementations.