Understanding Single Sign‑On (SSO) Mechanism and Its Java Implementation

Web applications use the browser/server architecture where HTTP is a stateless protocol; each request is processed independently, so the server must maintain state together with the browser to protect resources. This is achieved through a session mechanism that stores a session ID on the client (usually via a cookie) and on the server.

In a single‑system scenario, the server creates a session on the first request, sends the session ID to the browser, and the browser includes this ID in subsequent requests, allowing the server to recognize the same user. The session ID can be passed as a request parameter or, more commonly, via a cookie such as JSESSIONID in Tomcat.

When multiple systems form an application suite, requiring a separate login for each system becomes impractical. Sharing cookies across domains is limited by domain scope, technology differences, and security concerns, making a unified login solution necessary.

Single Sign‑On (SSO) introduces an independent authentication center (the SSO server). Users log in once to the SSO server, which creates a global session and issues an authorization token. The token is passed to each subsystem, which validates it with the SSO server and creates a local (partial) session. The token flow is:

User accesses a protected resource in subsystem A; A redirects to the SSO server.

SSO server presents a login page; user submits credentials.

SSO server validates credentials, creates a global session, generates a token, and redirects back to subsystem A with the token.

Subsystem A validates the token with the SSO server, creates a local session, and grants access.

When the user accesses subsystem B, the same token is reused after validation, providing seamless access.

Logout is also centralized: a logout request from any subsystem triggers the SSO server to destroy the global session and notify all registered subsystems to invalidate their local sessions.

Implementation details (Java):

SSO client uses a LoginFilter (implemented as a Filter) to intercept unauthenticated requests, redirect to the SSO server, extract the token from request parameters, verify it via HTTP client, and set isLogin in the session.

SSO server provides endpoints for /login (validates credentials, creates a global session, stores the token in Redis, and returns success) and /logout (invalidates the global session and notifies registered subsystems).

Token generation example: String token = UUID.randomUUID().toString(); Token verification example using Apache HttpClient:

HttpPost httpPost = new HttpPost("sso-server-verify-url-with-token");
    HttpResponse response = httpClient.execute(httpPost);

Logout listener on the server side implements HttpSessionListener to trigger logout notifications to all subsystems.

All code snippets are kept intact within ... tags, and the overall flow demonstrates how SSO unifies authentication across multiple web systems while maintaining security and user convenience.