Understanding Single Sign-On (SSO) and OAuth2.0: Types, Implementations, and Frameworks

In the micro‑service era, users need to switch among multiple applications and services while keeping their login state, which can be achieved through Single Sign‑On (SSO) or OAuth2.0 authentication and authorization protocols.

1. Single Sign‑On (SSO) is an authentication method that allows a user who has logged in to one application to access other related applications without re‑entering credentials. It separates login authentication from business systems by using an independent login center.

SSO has several implementation schemes:

Session‑Based SSO: the first application creates a session ID stored in a browser cookie; subsequent applications validate the user by receiving the same session ID. This method is simple but inefficient for distributed systems because it requires session sharing across services.

Token‑Based SSO: typically uses JSON Web Tokens (JWT). After the first login, the server issues a token containing user information; the client stores the token and sends it with each request to other services, which validate the token. This approach is more secure and works across domains.

OAuth‑Based SSO: OAuth is an open standard that lets users authorize third‑party applications to access resources without sharing passwords. In an SSO context, a user logs in to an authorization server, obtains an access token, and uses that token to access resource servers.

SAML‑Based SSO: uses the Security Assertion Markup Language (XML) to exchange authentication and authorization data between an identity provider (IdP) and a service provider (SP). It is often combined with OAuth for stronger solutions but is more complex to maintain.

The choice of SSO scheme depends on the project's size and requirements; simple internal apps may use session‑based SSO, while large distributed systems benefit from token‑based or OAuth‑based SSO.

2. OAuth2.0 is an open authorization protocol that allows users to grant third‑party applications access to resources stored with a service provider. It defines four grant types: authorization code, implicit, password, and client credentials. The authorization code flow is the most common for server‑side web applications.

OAuth2.0 itself does not provide SSO functionality, but when combined with SSO techniques it can achieve a single‑sign‑on experience. Popular Java frameworks that implement OAuth2.0 include:

Spring Security OAuth – an extension of the Spring framework offering comprehensive OAuth2 support, including configuration of authorization servers, resource servers, and clients.

Keycloak – an open‑source identity and access management solution supporting OAuth2, OpenID Connect, and other protocols, with a user‑friendly admin console.

Apache Oltu – a Java library implementing OAuth2, simplifying the creation of OAuth2 clients and servers and supporting multiple grant flows.

These frameworks handle token generation, validation, refresh, and revocation, allowing developers to focus on business logic.

3. SSO vs. OAuth2.0 – SSO primarily addresses seamless user navigation and login state across multiple services via a centralized login center, while OAuth2.0 focuses on delegated authorization and access control, involving users, third‑party apps, authorization servers, and resource servers. Combining both can provide a robust, flexible authentication solution for modern micro‑service architectures.