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

This article explains the fundamentals of HTTP's stateless nature, session handling, and login state, then introduces the challenges of multi‑system environments and presents a detailed overview of Single Sign‑On (SSO) concepts, flow, deployment, and step‑by‑step Java code examples for both client and server sides.

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

The article begins by describing HTTP as a stateless protocol and explains why a session mechanism is required to maintain user state across requests, using cookies (e.g., JSESSIONID) to store a session ID.

It then details how a server creates a session on the first request, returns the session ID to the browser, and how subsequent requests include this ID either as a request parameter or via cookies, allowing the server to recognize the same user.

Login state is stored in the session object; example Java code shows setting and retrieving an "isLogin" attribute:

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

The article then discusses the complexity of multi‑system applications, noting that cookie domain restrictions prevent a single login from working across different domains or technology stacks, which motivates the need for Single Sign‑On (SSO).

SSO is defined as a mechanism where a user logs in once to an authentication center (SSO server) and receives an authorization token that can be used by multiple subsystems (SSO clients) to create local sessions without re‑authenticating.

The SSO login flow is described step‑by‑step:

User accesses a protected resource in System 1 and is redirected to the SSO server.

SSO server presents a login page.

User submits credentials; the server validates them, creates a global session, and generates a token.

The token is sent back to System 1, which validates it with the SSO server and creates a local session.

The same token is used by System 2 (and other subsystems) to establish their own local sessions without further login.

Logout is also single‑point: when the user logs out from any subsystem, the subsystem notifies the SSO server, which destroys the global session and informs all registered subsystems to invalidate their local sessions.

A deployment diagram shows the SSO server communicating with multiple SSO clients via HTTP, with token exchange and session listeners.

Implementation details for Java are provided:

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

Sample filter code:

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");
}

SSO server provides login and logout endpoints; login sets the "isLogin" attribute and returns a token, logout invalidates the session.

@RequestMapping("/login")
public String login(String username, String password, HttpServletRequest req) {
    this.checkLoginInfo(username, password);
    req.getSession().setAttribute("isLogin", true);
    return "success";
}
@RequestMapping("/logout")
public String logout(HttpServletRequest req) {
    HttpSession session = req.getSession();
    if (session != null) {
        session.invalidate(); // triggers LogoutListener
    }
    return "redirect:/";
}

Token generation uses UUID.randomUUID().toString(), and token verification is performed by the client via an HTTP POST to the SSO server.

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

Tokens and registered subsystem URLs are stored in a key‑value store such as Redis, enabling fast lookup and expiration handling.

A LogoutListener implements HttpSessionListener to listen for global session destruction and notify all subsystems to clear their local sessions.

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

The article concludes with a brief note encouraging readers to like and share the post.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

BackendJavaSecuritySession ManagementSSO
Java Captain
Written by

Java Captain

Focused on Java technologies: SSM, the Spring ecosystem, microservices, MySQL, MyCat, clustering, distributed systems, middleware, Linux, networking, multithreading; occasionally covers DevOps tools like Jenkins, Nexus, Docker, ELK; shares practical tech insights and is dedicated to full‑stack Java development.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.