Sa-Token: a Java authorization framework built around one static call

Adding the Spring Boot starter is the whole install step

The README's installation section is one Maven dependency and nothing else, no configuration file and no bean to declare:

``` xml <!-- Sa-Token 权限认证, 在线文档：https://sa-token.com --> <dependency> <groupId>cn.dev33</groupId> <artifactId>sa-token-spring-boot-starter</artifactId> <version>1.46.0</version> </dependency> ```

The coordinates are worth noting because they do not match the group id most people would guess from the repository owner. The artifact is published under `cn.dev33`, while the repository lives under `dromara`, and the project is hosted on Gitee, GitHub and AtomGit at the same path. That arrangement is normal for Chinese open source projects and it matters if your organisation has an internal mirror keyed on group id.

Integration is not limited to Spring Boot. The README names integration packages for Spring Boot 2, Spring Boot 3, Spring Boot 4, Solon and JFinal, and the module list adds SpringMVC, WebFlux and Spring Cloud coverage, with a JDK 8 to 25 badge at the top of the page. Integration packages are split out rather than bundled, so the framework you actually compile against is the one matching your web stack.

Login and permission checks are static calls, not beans

The design decision that defines this framework is that authentication state is reached through a static utility rather than an injected object. Logging a user in is one call with the account id:

``` java // 会话登录，参数填登录人的账号id StpUtil.login(10001);

Requiring authentication on an endpoint is another:

java // 校验当前客户端是否已经登录，如果未登录则抛出 `NotLoginException` 异常 StpUtil.checkLogin();

Kicking a session off is the same shape:

java // 将账号id为 10077 的会话踢下线 StpUtil.kickout(10077);

The trade-off is real and worth naming. Static access removes an entire category of plumbing, and it is why the README argues that migrating from Shiro or Spring Security feels like a step change. What you give up is testability through dependency injection and compile-time visibility into what a handler touches. If your team relies on Spring's proxy-based AOP to intercept security calls, that habit has to change. The permission annotation is the part that keeps checks near business code rather than in a filter:

java // 注解鉴权：只有具备 `user:add` 权限的会话才可以进入方法 @SaCheckPermission("user:add") public String insert(SysUser user) { // ... return "用户增加"; }

A routing interceptor is available for the cases where a check should apply to a whole path prefix instead of one method:

java // 根据路由划分模块，不同模块不同鉴权 registry.addInterceptor(new SaInterceptor(handler -> { SaRouter.match("/user/**", r -> StpUtil.checkPermission("user")); SaRouter.match("/admin/**", r -> StpUtil.checkPermission("admin")); SaRouter.match("/goods/**", r -> StpUtil.checkPermission("goods")); })).addPathPatterns("/**"); ```

Five declared modules and a long tail of optional features

The README declares five core modules: login authentication, permission authentication, single sign-on, OAuth2.0 and microservice authentication. Underneath that sits a much longer feature list, and the list itself is the most honest description of what the framework covers.

Session behaviour runs from the basic to the unusual. Single-device login, multi-device login and same-device mutual exclusion are separate entries, as is a seven-day password-free mode, a remember-me mode that survives a browser restart, and a second-level authentication step that re-verifies an already logged in session. Kicking works by account id or by token value, and there is a feature for logging in as another account in real time, plus temporary identity switching.

The storage and delivery side covers Redis integration for data that must survive a restart, distributed sessions through a shared data centre, and a separate Redis mode that splits permission caching from business caching. Token delivery is described as six built-in token styles with a custom generation strategy on top, plus HTTP Basic and Digest authentication in one line, a global listener for login, logout and kick events, and a global filter for CORS and security response headers.

Two entries stand out as solving problems most frameworks leave to you: RPC call authentication, so service to service calls are not unauthenticated, and parameter signature verification, described as protecting against parameter tampering and request replay. There is also temporary token authentication for short-lived authorization windows, and Quick login authentication, which injects a ready login page with no code.

Three SSO topologies for three deployment shapes

Single sign-on is documented as three modes chosen by where the front end and the back end sit, and the README is explicit that mode three is the fallback when the first two are impossible.

Mode one covers systems sharing a parent domain with a shared Redis, where the front ends are same-origin and the session is synchronised through a shared cookie. Mode two covers different front-end domains with a shared back-end Redis, where the session propagates by URL redirect. Mode three covers different front-end domains and different Redis instances, where an HTTP request validates a ticket to obtain the session. Each mode has a documentation link and a runnable demo module named in the tree, `sa-token-demo-sso1-client` through `sa-token-demo-sso3-client`, so the three shapes can be read as worked examples rather than prose.

Two details in that section are the reason to read it rather than skim it. There is a no-SDK mode with a documented sso-server interface, which means a non-Java or non-Sa-Token system can participate, and there are multiple security checks layered on ticket flow: domain validation, ticket validation and parameter signature validation, aimed at ticket hijacking and replay. Single logout is also supported, where logging out in any one subsystem takes every subsystem offline, which is the feature most home-grown SSO attempts get wrong.

Reading the releases for security-relevant changes

The release notes are where this project is most candid, and they are worth reading as a security record rather than a feature list. Version v1.46.0, published 2026-08-19, adds pre-logout, pre-kickout and pre-replacement hooks to the listener, and adds a `loginType` parameter to `StpInterface.isDisabled` plus a new `allowLoginIdColon` setting that forbids colons in login ids by default. Both of those are marked as not downward compatible, which means an upgrade can break compilation or behaviour in code you did not touch.

The same release fixes a Jackson `DefaultTyping` polymorphic deserialization remote code execution issue by adding a global type allowlist through `SaJsonStrategy`, and switches random string and number generation to `SecureRandom`. That pair of changes is the kind of detail that tells you what the maintainer prioritises. Smaller fixes in the same release cover a null check in `getCookieTimeout`, IPv6 handling in `isUrl` that accepts bracketed addresses and rejects bare ones, and type-safe collection reads on Session.

Version v1.45.0, published 2026-03-09, adds a repeat-login strategy that can either kick the earlier session or reject the new login when an account is single-device, adds a `sa-token-jackson3` plugin for Jackson 3, and adds a `sa-token-snack4` plugin. Version v1.44.0, published 2025-06-07, fixes SSO logout failures across all ends and adds OAuth2 methods for reading advanced and low-level permissions from a `SaOAuth2DataLoader` interface. The repository is not archived and the last push was on 2026-09-18, one month after v1.46.0 shipped.

What the module tree shows about scope

The repository root explains more about the project's shape than the feature list does. There is `sa-token-core/` for the framework itself, `sa-token-bom/` and `sa-token-dependencies/` for version management, `sa-token-plugin/` for the integrations, `sa-token-starter/` for the framework starters, `sa-token-doc/` alongside `sa-token-doc-new/` for two generations of documentation, `sa-token-testing/`, and `sa-token-demo/`.

Two observations follow. First, the presence of `sa-token-doc` and `sa-token-doc-new` in parallel suggests the documentation site is mid-migration, and the README does link a preview-doc script, so the doc you land on may differ from the one a search result points at. Second, a `sa-token-demo` module with one directory per SSO mode tells you the maintainers expect you to read working code, not only prose.

The build side is Maven only at the root, with `pom.xml` and three Windows batch scripts for clean, test and coverage runs. There is no Gradle build, which is the opposite of Sa-Token's own multi-framework pitch and worth checking against your build conventions before you commit to it. The README itself exists in seven language variants including `README_en.md`, `README_ja.md`, `README_ko.md` and `README_ru.md`, and the canonical documentation lives at sa-token.com rather than in the repository, so the README is a front door to a much larger doc site rather than the manual itself.

Editorial conclusion

Sa-Token is a good fit when you want login and permission checks to read as one line of Java and you would rather not assemble that from Spring Security filter chains yourself. The cost is that the framework's design opinions become your design opinions: five modules, three SSO topologies and a wide plugin tree that you inherit wholesale. The releases show real maintenance, including a Jackson deserialization RCE fix and CSPRNG token generation in v1.46.0, and also two changes flagged as not downward compatible, so read the release notes before upgrading rather than after. Start with the Spring Boot starter dependency and the getting started chapters on sa-token.com, then decide which of the optional modules your architecture actually needs.

Frequently asked questions

Official sources

1. dromara/Sa-Token on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases