Sa-Token is a free, open-source, one-stop Java authentication and authorization framework, licensed under Apache-2.0, that gives Java and Spring Boot developers login authentication, permission checks, distributed sessions, single sign-on, OAuth2.0, gateway authentication, JWT integration, API key authorization and API parameter signing from a single dependency.

What it is

Sa-Token is a lightweight Java permission authentication framework built around five core modules: login authentication, permission authentication, single sign-on, OAuth2.0, and microservice authentication. It lives in the Java web ecosystem and ships integration packages for Spring Boot 2, Spring Boot 3 and 4, SpringMVC, WebFlux, Solon and JFinal, so it can be dropped into most common web frameworks without a configuration file. The maintainers describe the design goal as making the permission layer of a system simple and elegant rather than verbose.

The concrete problem it solves is the amount of boilerplate a team otherwise writes by hand: session login, token issuance, permission and role checks, kick-out, account bans, session queries and cross-service login state. It also replaces dedicated security frameworks, and the README states directly that developers who have used Shiro or Spring Security will see a substantial improvement after switching. Instead of implementing interfaces and writing configuration, a login is one static call, StpUtil.login(10001), and a login check is StpUtil.checkLogin(), which throws NotLoginException when the client is not authenticated.

Key capabilities

• Login authentication via StpUtil.login(10001) and StpUtil.checkLogin(), with single-device login, multi-device login, mutually exclusive login on the same device type, and seven-day remembered login.
• Annotation-based authorization such as @SaCheckPermission("user:add"), plus route interception through SaInterceptor and SaRouter.match("/user/**", ...) for RESTful modules.
• Kick-out by account ID with StpUtil.kickout(10077) or by token value, alongside account bans classified by business type and penalty tier.
• Single sign-on in three built-in modes covering same-domain, cross-domain, shared Redis, cross-Redis, front-end and back-end separated, Vue 2, Vue 3, pure JavaScript, Java and non-Java projects, with single logout that takes every subsystem offline.
• OAuth2.0 server support including the openid mode, and JWT integration in three modes with token extension parameters.
• Microservice authentication for Gateway, ShenYu and Zuul, plus RPC authentication and login-state propagation packages for Dubbo and gRPC so calls do not lose session state.
• Distributed session over Redis, an independent Redis for separating permission cache from business cache, API parameter signing to prevent tampering and replay, and password helpers for MD5, SHA1, SHA256 and AES.

Who uses it and how

• Spring Boot applications adding a permission layer to an existing service, where the starter handles sessions and annotations without a configuration file.
• Spring Cloud microservice systems that need authentication at the gateway and propagated login state across Dubbo or gRPC calls.
• Organizations running several subsystems that need single sign-on and a single logout that terminates every session at once.
• Front-end and back-end separated products such as apps and mini-programs, which cannot rely on cookies.
• Systems with multiple account tables, for example a mall where the User table and the Admin table are authenticated separately.

Getting started

Add the dependency cn.dev33:sa-token-spring-boot-starter:1.46.0 to pom.xml, or install one of the framework-specific integration packages for Spring Boot 3/4, Solon or JFinal. Documentation lives at https://sa-token.com, and the README notes that master is the learning and testing branch while dev is the development branch.

How it compares

The README names Shiro and Spring Security as the tools developers typically come from, and positions Sa-Token as a lighter replacement for both in the Java permission layer. It does not list any commercial product it substitutes, so it stands among open-source Java authentication frameworks rather than against paid identity platforms. The distinction it claims is one-line API ergonomics and breadth of built-in modules rather than a hosted service.

When to use it — and when not to

A self-hoster must operate Redis if sessions need to survive a restart or be shared across nodes, and must accept that persistence, cache separation and distributed session behavior depend on that infrastructure. The project is documentation-heavy and Chinese-first, with English, Japanese, Korean, Russian and Traditional Chinese READMEs available, so teams without Chinese readers may find the deepest material harder to follow. It is a poor fit for teams that want a hosted identity provider with an operations staff, or that need a formal commercial support contract.

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

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

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

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

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

// 根据路由划分模块，不同模块不同鉴权 
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"));
	SaRouter.match("/orders/**", r -> StpUtil.checkPermission("orders"));
	SaRouter.match("/notice/**", r -> StpUtil.checkPermission("notice"));
	// 更多模块... 
})).addPathPatterns("/**");