Understanding Single Sign-On (SSO) and OAuth2.0: Differences, Implementation, and CAS Workflow

Hello everyone, I am Chen Mou. My video tutorial "Spring Cloud Alibaba Practical Project" has been completed, covering Alibaba middleware, OAuth2 microservice authentication, full‑link gray release, and distributed transaction practice.

SSO (Single Sign‑On) and OAuth are both token‑based authentication methods, but they differ conceptually; many people confuse them.

The OAuth2.0 content is introduced in the Spring Cloud Alibaba practical project source code, as shown in the diagram below.

What Is Single Sign‑On

In short, users log in once and gain access to all subsystems within the permission scope, and logout works the same way.

For example, logging into Baidu.com automatically logs you into Baidu Baike, Baidu Zhidao, Baidu Tieba, etc.

Differences Between SSO and OAuth2.0

Although OAuth2.0 can achieve SSO, there are notable differences:

Trust Perspective: OAuth2.0’s authorization server and third‑party client are not mutually trusted (e.g., WeChat and a third‑party app), while SSO’s server and clients belong to the same trusted product suite.

Resource Perspective: OAuth2.0 lets users decide whether a third‑party can access their resources on the provider, whereas SSO’s resources reside in the client side and the SSO server mainly handles login and permission management.

Process Perspective: OAuth2.0 requires the third‑party to obtain an Access Token using a pre‑negotiated secret; SSO does not need this step.

OAuth2.0 can implement SSO, but it focuses more on protecting the provider’s resources. Understanding these differences helps you choose the right solution.

Implementing Single Sign‑On

Using OAuth2.0 for SSO is straightforward: each microservice integrates with the OAuth2.0 authentication service, obtains a token, and the gateway forwards it to downstream services, enabling one‑time login.

Besides OAuth2.0, many frameworks can achieve SSO; a classic example is the CAS framework.

The official CAS workflow diagram is shown below. Note:

SSO is a concept, and CAS is just one framework that implements it.

The CAS flow can be summarized as:

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.

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

The application receives the ticket, validates it with CAS, obtains user info, creates a local session (e.g., JSESSIONID), and returns it to the browser.

Subsequent interactions use the session ID without further password prompts.

The process and configuration are relatively complex, and many developers feel discouraged; a detailed CAS setup guide will be provided later.

A common real‑world example is the Taobao app: clicking links to Tmall, Juhuasuan, etc., does not require another login.

Conclusion

Understanding the differences between OAuth2.0 and SSO is essential. OAuth2.0 offers a simpler way to achieve SSO, while CAS provides a more feature‑rich but complex solution; developers should choose based on their project’s needs and complexity.

Final Note (Please Follow)

All my articles are carefully crafted. I have compiled three columns into PDFs. You can obtain them by following the "Java Backend Interviewer" public account and replying with the corresponding keywords:

Spring Cloud Advanced – reply with "Spring Cloud Advanced".

Spring Boot Advanced – reply with "Spring Boot Advanced".

MyBatis Advanced – reply with "MyBatis Advanced".

If this article helped you, please like, view, share, and bookmark—it’s the biggest motivation for me to keep going.