Understanding Single Sign-On (SSO) Mechanism and Java Implementation

Web applications use the stateless HTTP protocol, which requires a session mechanism to maintain user state across multiple requests. The server creates a session ID and sends it to the browser, typically stored in a cookie (e.g., JSESSIONID), allowing the browser to include the session ID automatically in subsequent requests.

In a single‑system scenario, this cookie‑based session works well, but when multiple systems form an application suite, users would otherwise need to log in to each system separately. Sharing cookies across domains is limited and often impractical, leading to the need for a unified authentication approach.

Single Sign‑On (SSO) solves this by introducing an independent authentication center (the SSO server) that handles user login and issues an authorization token. After successful login, the token is passed to each subsystem (SSO client), which validates the token with the SSO server and creates a local session.

SSO Login Flow:

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

The SSO server presents a login page; the user submits credentials.

Upon successful authentication, the SSO server creates a global session and generates a token (e.g., String token = UUID.randomUUID().toString();).

The SSO server redirects the user back to subsystem 1 with the token as a URL parameter.

Subsystem 1 receives the token, calls the SSO server to verify it, and, if valid, marks the local session as logged in.

When the user later accesses subsystem 2, the same token is presented, verified, and a local session is created without requiring another login.

Key Java code snippets illustrate the implementation:

Login filter in the SSO client that intercepts unauthenticated requests and redirects to the SSO server:

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
    HttpServletRequest req = (HttpServletRequest) request;
    HttpServletResponse res = (HttpServletResponse) response;
    HttpSession session = req.getSession();
    if (session.getAttribute("isLogin")) {
        chain.doFilter(request, response);
        return;
    }
    // Redirect to SSO authentication center
    res.sendRedirect("sso-server-url-with-system-url");
}

Setting login status in a servlet after successful authentication:

public String login(String username, String password, HttpServletRequest req) {
    this.checkLoginInfo(username, password);
    req.getSession().setAttribute("isLogin", true);
    return "success";
}

Token verification request using HttpClient:

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

Logout handling in the SSO client:

@RequestMapping("/logout")
public String logout(HttpServletRequest req) {
    HttpSession session = req.getSession();
    if (session != null) {
        session.invalidate(); // Trigger LogoutListener
    }
    return "redirect:/";
}

Logout listener on the SSO server that notifies all registered subsystems when the global session is destroyed:

public class LogoutListener implements HttpSessionListener {
    @Override
    public void sessionCreated(HttpSessionEvent event) {}
    @Override
    public void sessionDestroyed(HttpSessionEvent event) {
        // Use HttpClient to send logout requests to all registered systems
    }
}

By separating authentication (SSO server) from resource access (SSO clients), the architecture ensures that a user logs in once and gains authorized access to all participating systems, while also providing a coordinated single‑point logout that invalidates both global and local sessions.