Understanding SSO and OAuth 2.0: Concepts, Differences, and Implementation

1. Overview

SSO (Single Sign‑On) and OAuth 2.0 both use token‑based authentication to replace user passwords when accessing applications. SSO separates login authentication from business systems via an independent login center, allowing users to log in once and access multiple services without re‑entering credentials. OAuth 2.0 is a protocol that enables third‑party applications to obtain delegated access to a user's resources, often seen in social‑login scenarios such as WeChat authorization.

2. SSO

SSO is a conceptual approach; frameworks like CAS implement this idea. The typical SSO flow includes:

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 logged in; if not, it redirects to the login page, otherwise it creates a global session and redirects back to the business system.

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

Upon successful validation, the SSO system issues a ticket and redirects the user to the business system.

The business system receives the ticket, validates it with the SSO server, obtains user information, creates a local session (e.g., sessionId or Tomcat’s JSESSIONID ), and returns a successful login response.

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

Typical example: opening the Taobao app and clicking a link to Tmall or Juhuasuan directly jumps to the target service without another login.

3. OAuth 2.0

OAuth 2.0 has several grant types; the article focuses on the Authorization Code flow. In an SSO‑like scenario, only an authorization server and a client are needed (the resource server can be omitted).

The authorization server handles authentication, while the client (the business application) receives user information and permissions after successful login.

User clicks “Login with WeChat” on a website; the website acts as the client, and WeChat’s authorization server acts like an SSO system.

WeChat presents a login/authorization page.

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

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

OAuth 2.0 Grant Types

Authorization Code

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

Implicit

Used by pure front‑end applications; the token is returned directly to the client without an intermediate code.

Password

Applicable when the client is highly trusted; the user’s username and password are sent directly to obtain a token.

Client Credentials

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

4. Terminology Differences

SSO is an abstract concept or solution pattern; implementations like CAS realize this idea.

OAuth 2.0 is a protocol for delegating access to resources; it can be leveraged to achieve SSO, with tokens (often JWT) carrying user identity and permissions.

Spring Security and Shiro are Java frameworks for securing applications and controlling access permissions.

5. Promotional Invitation

The author invites readers to join a knowledge‑sharing community that provides ChatGPT accounts, tutorials, interview materials, and other resources, offering limited‑time discounts and exclusive benefits.