Mastering Single Sign-On: From Session Basics to Java Implementation

1. Single‑System Login Mechanism

1.1 HTTP is a stateless protocol

Web applications follow a browser/server model where each HTTP request is processed independently, so the server must maintain state itself to protect resources.

1.2 Session mechanism

When the browser first accesses the server, the server creates a session and returns a session ID. The browser stores this ID (usually in a cookie) and sends it with subsequent requests, allowing the server to recognize the same user.

1.3 Storing the session ID

Two common ways:

Pass the session ID as a request parameter (not reliable).

Use a cookie. Browsers automatically attach cookies to matching domain requests. In Tomcat the cookie is named JSESSIONID.

1.4 Login state

After successful username/password verification, the server marks the session as logged in, e.g.:

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

Later requests check this attribute to grant access.

2. Complexity of Multi‑System Environments

When an application consists of many subsystems, requiring separate logins for each is impractical. Cookies are scoped to a domain, so sharing a session across different domains or technology stacks (Java, PHP, .NET) is impossible, and cookies are not secure enough. Therefore a new approach—Single Sign‑On (SSO)—is needed.

3. Single Sign‑On (SSO)

SSO allows a user to log in once to an authentication center and be authorized across all subsystems without re‑entering credentials.

3.1 Login flow

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

SSO server shows the login page.

User submits credentials; SSO server validates them.

SSO server creates a global session and generates an authorization token.

SSO server redirects back to System 1 with the token.

System 1 validates the token with the SSO server and creates a local session.

User accesses System 2; System 2 redirects to the SSO server.

SSO server sees the user is already logged in, redirects back with the token.

System 2 validates the token and creates its own local session.

Constraints:

If a local session exists, a global session must exist.

A global session may exist without any local session.

Destroying the global session must also destroy all local sessions.

4. Deployment Overview

SSO consists of an SSO server (authentication center) and multiple SSO clients (subsystems). Clients must integrate an SSO client library to exchange tokens, validate them, and handle logout notifications.

5. Implementation Sketch (Java)

5.1 sso‑client: intercept unauthenticated requests

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") != null) {
        chain.doFilter(request, response);
        return;
    }
    // redirect to SSO server
    res.sendRedirect("sso-server-url-with-system-url");
}

5.2 sso‑server: login endpoint

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

5.3 Token generation

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

5.4 Token validation (client side)

// request carries token parameter
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);
}

5.5 Token validation (server side)

The SSO server stores tokens (e.g., in Redis) with an expiration time and checks existence/validity when a client queries.

5.6 Logout flow

User sends a request with a logout parameter to a subsystem.

The subsystem forwards the request to the SSO server.

The SSO server invalidates the global session and notifies all registered subsystems.

Each subsystem destroys its local session (via a LogoutListener implementing HttpSessionListener).

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
    }
}

With these components, a user logs in once and gains seamless access to all participating systems, while a single logout clears every session.