Understanding Single Sign-On (SSO) and Session Management in Web Applications

Web applications use the browser/server architecture with HTTP as a stateless protocol, meaning each request is processed independently without any built‑in link to previous requests.

To protect server resources, a session mechanism is introduced where the server creates a session ID on the first request, sends it to the browser, and the browser returns the ID on subsequent requests, typically via cookies (e.g., JSESSIONID in Tomcat).

Login status is stored as an attribute in the session object, for example:

HttpSession session = request.getSession();
session.setAttribute("isLogin", true);

When a protected resource is accessed, the server checks the isLogin attribute; only sessions with true are allowed.

In multi‑system environments, using a single cookie domain is impractical due to domain restrictions, technology heterogeneity, and security concerns, leading to the need for Single Sign‑On (SSO).

SSO introduces a central authentication server (SSO‑server) that issues a token after successful login. Sub‑systems (SSO‑clients) redirect unauthenticated users to the SSO‑server, receive the token, validate it, and create a local session.

The SSO flow includes:

User requests a protected resource in System 1 → redirected to SSO‑server.

User logs in at SSO‑server → global session and token created.

SSO‑server redirects back to System 1 with token.

System 1 validates token, creates a local session, and serves the resource.

When accessing System 2, the token is reused, avoiding another login.

Global and local sessions have the following relationships:

Local session exists only if a global session exists.

Destroying the global session must also destroy all local sessions.

Implementation details (Java):

SSO‑client uses a Filter (e.g., LoginFilter) to intercept unauthenticated requests and redirect to the SSO‑server.

After login, the SSO‑server generates a token (e.g., String token = UUID.randomUUID().toString();) and stores it (commonly in Redis).

SSO‑client validates the token via HTTP client calls and, upon success, marks the session as logged in.

Logout is handled centrally: a logout request to the SSO‑server invalidates the global session and notifies all registered systems to destroy their local sessions.

Key code snippets:

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 server
    res.sendRedirect("sso-server-url-with-system-url");
}

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

String token = UUID.randomUUID().toString();

String token = req.getParameter("token");
if (token != null) {
    boolean verifyResult = this.verify("sso-server-verify-url", token);
    if (!verifyResult) {
        res.sendRedirect("sso-server-url");
        return;
    }
    chain.doFilter(request, response);
}

Logout handling example:

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

The LogoutListener implements HttpSessionListener to notify all registered systems when the global session is destroyed.

Overall, the article provides a comprehensive overview of session management, the limitations of cookie‑based single‑system login, and a step‑by‑step guide to implementing SSO in Java web applications.