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

Overview – SSO (Single Sign-On) and OAuth2.0 both use token‑based authentication to replace user passwords when accessing applications, but they differ in concept and typical usage.

SSO separates login authentication from business systems by providing an independent login center; after a user logs in once, all related business systems can access resources without additional login.

OAuth2.0 is a protocol that allows third‑party applications to obtain permission to access a user's resources on another server; it is widely used in scenarios such as “login with WeChat” where the user does not need to register on the target site.

SSO

SSO is a design philosophy; CAS is one framework that implements this idea. The typical SSO flow includes:

User accesses a protected application ( Protected App ) and is redirected to the CAS server ( 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.

After the user submits credentials, the CAS server validates them and issues a ticket.

The browser redirects back to the business system with the ticket; the business system validates the ticket, creates a local session ( sessionId , known as JSESSIONID in Tomcat), and grants access.

Subsequent interactions use the sessionId instead of re‑entering credentials.

Typical example: opening the Taobao app and clicking links to Tmall or Juhuasuan without being prompted to log in again.

OAuth2.0

OAuth2.0 supports several grant types; this article focuses on the Authorization Code flow, which resembles SSO but involves an authorization server and a client (the business system). The steps are:

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

WeChat presents an authorization page (its own login UI) to the user.

After the user authorizes, WeChat returns a ticket and redirects back to the client.

The client exchanges the ticket for an access token (often a JWT) and uses the token to retrieve user information.

OAuth2.0 Four Grant Types

Authorization Code – Most common, suitable for server‑side web applications; the code is exchanged for a token on the backend, keeping the token secure.

Implicit – Designed for pure front‑end applications; the token is returned directly to the browser without an intermediate code.

Password – Used when the client is highly trusted; the user’s username and password are sent to the client, which then obtains a token.

Client Credentials – Used by command‑line or service‑to‑service applications that do not act on behalf of a user.

Simple Flow Diagram

Key Differences

SSO is an abstract concept or solution for unified authentication across multiple systems, while OAuth2.0 is a protocol for delegated authorization; OAuth2.0 can be used to implement SSO, but its primary goal is to grant limited access to resources via tokens (often JWTs).

Frameworks such as Spring Security and Apache Shiro provide security and access‑control features for Java applications and can be used together with SSO or OAuth2.0 implementations.