Understanding SSO vs OAuth2.0: How Token‑Based Authentication Works

Overview

SSO (Single Sign On) and OAuth are token‑based methods that replace user passwords when accessing applications. They have similar flows but different concepts. SSO separates authentication from business systems via a central login center, allowing users to access all related services without re‑entering credentials.

OAuth2.0 also uses tokens; a common example is using WeChat authorization to comment on a site without registering.

SSO

SSO is a concept; frameworks such as CAS implement it. The following steps describe a typical CAS‑based SSO flow.

User accesses a protected application ( Protected App ) which redirects to the CAS server with a service parameter.

Browser redirects to the CAS login system; if not logged in, the user is sent to the login page, otherwise a global session is created and the user is redirected back.

User submits password at the CAS login page; only the CAS system stores the password.

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

Business system receives the ticket, calls CAS to obtain user info, creates a local session ( sessionId , e.g., JSESSIONID in Tomcat) and returns it to the browser.

Subsequent interactions use the sessionId to communicate with the business system.

Typical example: opening a link in the Taobao app jumps directly to Tmall or Juhuasuan without another login prompt.

OAuth2.0

OAuth2.0 has several grant types; the article focuses on the authorization‑code flow. In an SSO scenario only an authorization server and a client are needed.

The authorization server handles authentication; the client is the application that receives user information and permissions after login.

User clicks “Login with WeChat” on a website; the website acts as the client and WeChat acts as the authorization server.

WeChat shows an authorization page (login UI) to the user.

User authorizes, WeChat validates credentials and returns a ticket, then redirects back to the client.

Client exchanges the ticket for an access token and uses it to obtain user information.

OAuth2.0 Grant Types

Authorization Code

Most common, suitable for web apps with a backend; the code is exchanged for a token on the server side.

Implicit

For pure front‑end apps; the token is issued directly to the browser without an intermediate code.

Password

When the client is highly trusted, the user can provide username and password directly to obtain a token.

Client Credentials

Used by command‑line or service‑to‑service applications without a user interface.

Key Terminology Differences

SSO is an architectural idea for single‑sign‑on.

OAuth2 is a protocol for delegated authorization; it can be used to implement SSO, typically issuing JWT as the access token.

Spring Security, Shiro are Java frameworks for access control.