SSO vs OAuth2.0: Key Differences Explained for Interviews

SSO (Single Sign‑On) and OAuth2.0 both replace passwords with tokens, but they differ conceptually: SSO separates authentication from business systems via a dedicated login center, allowing a user to log in once and access all related services without re‑authentication.

OAuth2.0 is a delegation protocol widely used (e.g., WeChat login). It also avoids storing passwords in business systems; credentials reside in the login center or the third‑party server, and a token is presented to the application.

SSO

Many frameworks implement the SSO idea; CAS is a typical example. The following steps illustrate a typical CAS‑based SSO flow:

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

The browser reaches the CAS server, which checks whether the user is already logged in. If not, it redirects to the login page; if yes, it creates a global session and redirects back to the business system.

The user submits credentials on the CAS login page; only the CAS system stores the password.

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

The business system receives the ticket, validates it with CAS, and creates a local session identified by sessionId (called JSESSIONID in Tomcat).

Subsequent interactions between the browser and the business system use the sessionId only.

Typical example: opening the Taobao app and clicking links to Tmall or Juhuasuan does not require another login because SSO shares the session.

OAuth2.0

OAuth2.0 offers several grant types; the article focuses on the authorization‑code flow, which resembles SSO but omits the resource server when used for single sign‑on. Roles include an authorization server and a client (the application).

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

WeChat’s authorization server presents a login/consent page.

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

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

The four OAuth2.0 grant types are briefly described:

Authorization code : most common, highest security, suitable for backend web apps; the token is stored server‑side.

Implicit : for pure front‑end apps; the token is issued directly to the browser.

Password : trusted applications can send username and password to obtain a token.

Client credentials : for command‑line or service‑to‑service scenarios without a front end.

A simple diagram (image) summarizes the OAuth2.0 flow.

Terminology Comparison

SSO is an abstract solution concept; OAuth2.0 is a protocol for delegated authorization, not originally designed for SSO but can be leveraged to implement it. In the example, JWT is used as the carrier of the access token. Java security frameworks such as Spring Security and Shiro provide access‑control mechanisms for these flows.