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

1. Overview

SSO (Single Sign‑On) and OAuth (Open Authorization) both use tokens instead of user passwords to access applications; while their processes are similar, their concepts differ. SSO separates authentication from business systems via an independent login center, allowing users to access all related services after a single login.

OAuth2.0 is often encountered in everyday scenarios, such as using WeChat authorization to comment on a website without registering; both systems store credentials in a central login center or third‑party server, and applications use tokens to access resources.

2. SSO

SSO is a conceptual approach; CAS is one framework that implements it. The typical SSO flow includes:

User accesses a protected application, which redirects to the CAS server with a service parameter.

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

User submits credentials on the CAS login page (the only place passwords are stored).

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

The business system receives the ticket, validates it with CAS, obtains user information, creates a local session (e.g., JSESSIONID), and completes login.

Subsequent interactions use the session ID without re‑authentication.

Typical example: opening the Taobao app and clicking links to Tmall or Juhuasuan leads directly to those services without another login.

3. OAuth2.0

OAuth2.0 has several grant types; this article focuses on the Authorization Code flow. The roles include an authorization server, a resource server, and a client. When using OAuth2.0 for SSO, only the authorization server and client are needed.

"The authorization server handles authentication, while the client is the application that receives the user’s information and permissions after a successful login."

User clicks a WeChat authorization button on a website (the website acts as the client, WeChat as the authorization server).

WeChat presents an authorization page (similar to a login page) to the user.

User confirms authorization, the server validates credentials and returns a ticket, then redirects back to the client.

The client exchanges the ticket for a token from WeChat and uses the token to obtain user information.

OAuth2.0 Grant Types

Authorization Code

The client first obtains an authorization code, then exchanges it for a token. This is the most common and secure flow, suitable for web applications with a backend where the token is stored server‑side.

Implicit

Designed for pure front‑end applications without a backend; the token is issued directly to the front end, omitting the authorization code step.

Password

If the client is highly trusted, the user can provide username and password directly to the client, which then requests a token.

Client Credentials

Used by command‑line or service‑to‑service applications that have no user interface, obtaining a token using only client credentials.

Simple Flow Diagram

4. Terminology Differences

SSO is an abstract concept or solution; implementation follows its principles.

OAuth2.0 is a protocol that allows users to authorize third‑party applications to access resources on another server; it is not designed for SSO, but can be used to achieve it.

In the SSO scenario, the protected resource is user information (basic profile and permissions). OAuth2.0’s server issues a JWT token that carries the Access_Token.

Spring Security and Apache Shiro are Java frameworks used for securing access and enforcing permissions.

Source: MarkerHub

Backend‑Specific Technical Community

Build a high‑quality technical exchange group; developers, recruiters, and anyone interested in sharing job referrals are welcome.

Maintain civil discussion focusing on technical exchange , job referrals , and industry topics .

Advertisements are prohibited; beware of private messages and scams.

Contact me to join the group.