Information Security 7 min read

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

This article explains the principles of Single Sign‑On (SSO) and OAuth2.0, compares their workflows, describes common implementation patterns such as CAS and token‑based authentication, and clarifies the distinctions between SSO, OAuth2.0, and related security frameworks.

IT Architects Alliance
IT Architects Alliance
IT Architects Alliance
Understanding SSO and OAuth2.0: Concepts, Processes, and Differences

SSO (Single Sign‑On) and OAuth2.0 both use tokens instead of user passwords to access applications, but they differ in concept: SSO separates authentication from business systems via a dedicated login center, while OAuth2.0 is a protocol for granting third‑party access to resources.

SSO is typically implemented with frameworks like CAS. The CAS flow includes the user accessing a protected application ( Protected App ), being redirected to the CAS server ( CAS Server ) with a service parameter, logging in at the CAS login page, receiving a ticket, and finally the business system validating the ticket and creating a session ( sessionId , known as JSESSIONID in Tomcat). Subsequent interactions use this session ID.

OAuth2.0, especially the authorization‑code grant, follows a similar redirection pattern but involves an authorization server, a resource server, and a client. In many SSO scenarios the resource server is omitted, leaving only the authorization server and client. After the user authorizes (e.g., via WeChat), the authorization server issues a ticket, which the client exchanges for an access token (often a JWT). The client then uses this token to retrieve user information.

The four OAuth2.0 grant types are:

Authorization Code – most secure, suitable for server‑side web apps.

Implicit – token issued directly to front‑end‑only apps.

Password – user credentials are sent to the client (trusted apps only).

Client Credentials – token for machine‑to‑machine communication.

Key distinctions:

SSO is an architectural idea; CAS is one concrete implementation.

OAuth2.0 is a protocol for delegated authorization, not originally designed for SSO, though it can be used to achieve SSO functionality.

Spring Security and Apache Shiro are Java frameworks that enforce access control once authentication (via SSO or OAuth2.0) is completed.

Typical real‑world example: opening the Taobao app and seamlessly accessing services like Tmall without re‑entering credentials, thanks to SSO mechanisms operating behind the scenes.

securityauthenticationCAStokenSSOOAuth2.0
IT Architects Alliance
Written by

IT Architects Alliance

Discussion and exchange on system, internet, large‑scale distributed, high‑availability, and high‑performance architectures, as well as big data, machine learning, AI, and architecture adjustments with internet technologies. Includes real‑world large‑scale architecture case studies. Open to architects who have ideas and enjoy sharing.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.