Understanding Single Sign‑On (SSO) Principles and a Simple Java Implementation

Web applications use the stateless HTTP protocol, so each request is independent; to maintain user state a session mechanism is introduced, typically backed by a cookie that stores a session ID (e.g., Tomcat’s JSESSIONID).

When a browser first accesses a protected resource, the server creates a session, returns the session ID, and the browser includes this ID in subsequent requests, allowing the server to recognize the same user.

Two common ways to carry the session ID are request parameters and cookies; cookies are preferred because browsers automatically attach them to matching domain requests.

Login status is stored in the session (e.g.,

HttpSession session = request.getSession();

session.setAttribute("isLogin", true);

) and later retrieved to decide whether the user is authenticated.

In multi‑system environments a user would otherwise need to log in to each system separately; sharing cookies across sub‑domains is limited by domain scope, technology stack differences, and security concerns, so a dedicated Single Sign‑On (SSO) approach is required.

SSO introduces an independent authentication center that validates credentials once, creates a global session and an authorization token, and then redirects the user back to the original system with the token as a parameter.

The token is verified by each subsystem (SSO client); upon successful verification the subsystem creates a local session (e.g., setting session.setAttribute("isLogin", true);) and registers itself with the SSO server.

Logout works by the client sending a logout request (including the token) to the SSO server, which destroys the global session and notifies all registered subsystems to invalidate their local sessions.

Implementation steps (Java):

SSO client uses a LoginFilter (implemented as a servlet filter) to intercept unauthenticated requests and redirect to the SSO server.

SSO server provides a login endpoint that validates credentials, creates the global session, and generates a token (e.g., String token = UUID.randomUUID().toString();).

After login, the server redirects back with the token; the client extracts the token ( String token = req.getParameter("token");) and calls the SSO server to verify it via HTTP client.

On successful verification the client marks the local session as logged in.

Both client and server maintain a registry (e.g., in Redis) mapping tokens to subsystem URLs to support single logout.

Logout endpoint on the SSO server invalidates the global session and iterates over the registry, sending HTTP requests to each subsystem to invalidate their local sessions (implemented with an HttpPost).

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") != null) {
        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();

Deployment diagram shows the SSO server communicating with multiple client systems via HTTP/REST; token storage and system registration are typically kept in an in‑memory store such as Redis for fast access.

Overall, the article walks through the theory of SSO, the problems it solves for multi‑system authentication, and provides a concrete, minimal Java example covering login, token generation, verification, session creation, and single logout.