XXL-SSO shares one login state across the Java systems you already run

One credential for every trusted Java system you run

XXL-SSO exists for one shape of problem: several systems that trust each other, which a user should be able to reach after typing a single password. Its own description calls it a distributed single sign-on framework, and the feature list is organised around deployment situations rather than around a protocol. A monolith that needs a shared session, an enterprise holding systems on different domains, and a fleet of mobile or front-back separated clients each get a different answer from this project. That situation-first structure is the reason to read it closely, because the choice you make on day one is which login type you take, and the framework does not hide that decision behind configuration.

What the page offers as evidence of real use is thin, and the dates attached to it are old. Eight companies are named as adopters, the list dated 2018-03-15 and described as not exhaustive, gathered for promotion rather than measured. Two ranking placements follow it: 55th on 2018-12-05 among more than ten thousand domestic projects, then 8th on 2019-01-23 in a chart for new projects of that year. Read as a whole, the adoption record stops in early 2018 while the code has moved on since.

Three replaceable components decide what a login means

The design puts three extension points between your application code and the thing that holds the credential. `LoginStore` persists the login state and session data, and official implementations are backed by Cache and by Redis, with `RedisLoginStore` named as the one to copy when you write your own. `Auth` is where login and authentication are integrated into the serving stack, and the official implementations cover a Servlet `Filter`, a Spring MVC `Interceptor` and a `WebFilter` for Spring WebFlux and reactive applications. `LoginInfo` is the unified user model, built so an application can hang extra attributes on it.

Access comes from an annotation or from an API call, described as a single line of annotation or code for login, permission and role checks. The practical consequence shows up on upgrade day: the pieces that need changing most, where the session lives and how it reaches the client, sit behind interfaces, while the authentication flow itself stays put.

Permission and role checks share one definition

Three checks are on offer, login authentication, permission authentication and role authentication. Read the two authorization entries side by side and they carry the same sentence, answering the same question about what a user may do, and they differ only in the dimension named, permission or role. That is the whole of it. No permission model is described anywhere on the page: there is no mention of a role table, an access control list, a resource tree or a policy language, only a check that runs after identity has been confirmed.

For a Java team this is a thinner contract than the word authorization normally carries. If your requirements include resource-level decisions, role hierarchies or per-object permissions, the project hands you an annotation and leaves the model to you, which is work the feature list does not count. A team whose authorization rules live in code already may find that acceptable. Everyone else will notice that gap in design review, well before integration begins.

Web login assumes one domain, Native login assumes a client

The three login types are not three flavours of one mechanism. They are three deployment contracts with three different bills attached. Web conventional login serves the plain monolith case and carries a hard constraint: the related web systems must sit under the same domain, because the credential is stored on that shared domain. Take it and cross-domain access is off the table by design, not by omission.

Native login targets mobile apps, mini programs, front-back separated services and desktop clients. It exists for situations without cookies, so no domain restriction applies, and it supports several terminals signed in at once while sharing login state. The cost moves to the client, which the documentation states plainly: the credential has to be managed and maintained by the client itself. That is engineering work in code you own on every platform you ship, not a configuration value. A team with one server-rendered monolith can take Web login and ignore the rest. A team shipping a mini program has no choice in the matter.

CAS buys cross-domain login with another service to run

The CAS path is aimed at multi-system cross-domain access and unified enterprise login. It solves precisely what the Web path cannot, at the price stated in the same breath: a CAS authentication centre has to be deployed separately, and that centre carries the basic single sign-on capability for everything attached to it.

Two further items come with it. A ticket design covers the redirect, and the centre can be deployed as a cluster with login state shared through a `LoginStore`, which is where horizontal scaling and high availability come from. That sits awkwardly against the opening claim of real out-of-the-box use. For the Web monolith case the claim holds. For CAS it does not: the centre is a service you build, deploy and keep alive, and while it is down, sign-in across every connected system stops. No failover story beyond the cluster option is described, and nothing explains what happens to sessions already issued when the centre restarts.

No install command, a Maven artifact and three modules

Here is the honest shape of the setup story, because the project page does not give one. There is no install command, no configuration key, no port and no upgrade note on it. What it offers instead is a pointer: the badge at the top links to Maven Central for the artifact path `com.xuxueli/xxl-sso-core`, and the repository root carries a `pom.xml` beside three Maven modules, `xxl-sso-core`, `xxl-sso-samples` and `xxl-sso-server`, plus `doc/` and `.github/` directories. Note what is absent from that root listing: no `src` directory, so nothing here is a single deployable application until you assemble one yourself. The documentation link leads to a Chinese page, which is the only prose guide on offer.

Maintenance signals are just as thin. Version 2.4.1 shipped on 2026-08-07, after 2.3.2 on 2025-12-28, and the last push was on 2026-09-27. A first working setup therefore starts with three decisions in a fixed order: which login type your topology forces, which `LoginStore` implementation holds the session, and which `Auth` adapter matches your stack, Servlet, Spring MVC or reactive. Only after those does the dependency question matter.

Half-window renewal keeps a session alive without a ceiling

Session lifetime has a small design of its own, and it is worth reading twice. A remembered login extends by itself; an unremembered one dies when the browser closes. Renewal is stated as a window: once the validity window is more than half elapsed, the login state is extended by one period. Apply that to a user who keeps working and the end of the window never arrives on its own. No maximum count, no absolute ceiling and no idle timeout appear in the documentation.

For an internal tool that is convenient. For anything reachable from outside your network it is the first rule to put in front of a security review, because the only expiry that fires by itself is the browser closing on a login that was not remembered. Distributed sessions work the way you would expect, with several instances pointing at one shared `LoginStore` and `RedisLoginStore` offered as the implementation to copy. Logout exists for the CAS scenario, where the centre can revoke across systems. For Native clients, nothing describes how a server side token is invalidated before it expires on its own.

Spring Security, Keycloak and the case for a separate identity server

Nothing on the project page compares XXL-SSO with anything else, so the comparison has to be made on architecture. Spring Security is a library of filters and method-level checks that each application assembles for itself, and sharing one login across systems is work the team does. Keycloak is the opposite shape: a separate identity server that applications talk to over a standard token protocol, so the session lives in one place by default and federation with outside partners is a supported configuration rather than an obstacle.

XXL-SSO sits between the two. The session lives in a store you run, applications need no protocol to learn, and the CAS path can centralise login the way Keycloak does. Against that, every application still embeds the framework, and no federation story exists. The trade is concrete: fewer extra services to operate, in exchange for interoperability with external identity providers and a permission model you build yourself. Teams with English-only documentation needs will also notice that the guide is in Chinese.

Terms are the other cost. It ships under the GNU General Public License version 3, with copyright held by xuxueli, so a product you do not publish under the same licence needs its own reading before the core goes in. The page describes no exception and no alternative grant.

Editorial conclusion

XXL-SSO fits a Java shop that already runs several trusted systems, can keep them under one domain or can operate a CAS centre, and wants the login state shared through a LoginStore it controls. It does not fit a team that needs token federation with outside partners, or a permission model documented rather than left to you. Verify two things before pricing the work: whether your applications can share one domain, and whether a Chinese-only guide is workable for the team that will run it. The page ships no install command, so the setup cost is yours to estimate.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. xuxueli/xxl-sso on GitHub