一般系统的登录鉴权是如何实现的

1、什么是登录鉴权？#

简单来说，登录鉴权就是解决一个问题：

“你是谁？你有没有权限访问这个资源？”

在实际系统中，几乎所有的功能都不是”谁都能用”的。比如：

• 用户必须先登录，才能看到自己的订单
• 管理员才能看到后台的用户管理页面
• 普通用户不能删除别人的数据

这就需要系统在用户访问资源时，先验证用户的身份，再判断用户有没有权限做这个操作。

2、登录鉴权包含两个核心概念#

这两个概念在实际开发中经常被一起提到，但它们做的事情是不同的：

• 认证：通常发生在登录阶段，验证用户名密码是否正确
• 授权：通常发生在用户访问某个接口或页面时，判断该用户是否有权限

3、为什么需要了解登录鉴权？#

虽然基本上不会让你从头实现登录鉴权，但它是几乎所有业务系统都有的功能，作为程序员还是要有一些基本认识。而且，入职后你大概率会碰到以下场景：

• 自测接口的时候，需要知道如何去传认证登录的参数
• 需要做接口鉴权的时候，要明白一般的鉴权逻辑，这样你才能更好的理解你们公司的鉴权方式
• 需要放行某些接口（不需要登录就能访问）的时候，要知道怎么配置，比如登录接口本身、注册接口、验证码接口、公开页面等
• 写业务代码时经常需要获取当前登录用户（比如记录”谁创建的""谁修改的”），要知道怎么从后端拿，而不是让前端传
• 和同事沟通登录鉴权相关需求的时候，要具备这方面基本的认知能力

1、前后端不分离项目#

前后端不分离的老项目的登录认证一般都是使用的 Session + Cookie 的方式。

1.1 工作流程#

1
你去银行办业务
2
        ↓
3
你拿着身份证去柜台验证身份（提交用户名密码）
4
        ↓
5
验证通过，柜台为你建立一份专属档案，并交给你一张号码牌
6
（登录成功，创建 Session，存入用户信息，通过 Set-Cookie 返回 JSESSIONID）
7
        ↓
8
你拿着号码牌去办业务（浏览器后续请求自动带上 Cookie）
9
        ↓
10
柜台看到号码牌，查到你的档案，办理业务（后端根据 Session ID 找到用户信息）

2、前后端分离的项目#

在前后端分离的项目中，我们通常采用 Token 机制 来实现登录认证，而 JWT 则是目前最常用的 Token 格式。

1
Header（头部）.Payload（载荷）.Signature（签名）

1
eyJhbGciOiJIUzI1NiJ9.eyJyb2xlIjoiQURNSU4iLCJ1c2VySWQiOjEsInZlcnNpb24iOjAsInVzZXJuYW1lIjoiYWRtaW4iLCJpYXQiOjE3ODA2MjkzNjAsImV4cCI6MTc4MTIzNDE2MH0.YMHDAIskTfOcOl4tjWFUUqwcBsvKA4O_xuD2wijezXQ

2.3 工作流程#

密钥（Secret Key）的作用说明

密钥是 JWT 安全性的核心，它只保存在服务端，不会泄露给前端。它的作用有两个：

• 生成 Token 时：后端用密钥对 Header 和 Payload 进行签名（计算出一个哈希值），拼接到 JWT 的第三部分（Signature）
• 校验 Token 时：后端用同一个密钥重新计算签名，如果和 JWT 中携带的签名一致，说明 Token 没有被篡改

如果密钥泄露了，任何人都可以伪造 JWT，所以密钥的安全保管非常重要。

1
你去景区玩
2
        ↓
3
售票处验证你的身份证（验证用户名密码）
4
        ↓
5
验证通过，给你一张"门票"（生成 JWT）
6
        ↓
7
门票上写了你的名字、有效期（JWT 的 Payload）
8
        ↓
9
门票上有景区的防伪印章（JWT 的 Signature）
10
        ↓
11
你每次进景点，工作人员看门票（后端校验 JWT）
12
        ↓
13
门票是真的且没过期 → 放行
14
门票是假的或已过期 → 拒绝进入

1、为什么需要获取当前登录用户？#

举几个你入职后一定会遇到的场景：

这些场景都有一个共同点：后端需要知道当前请求是谁发的，而不是让前端来告诉后端。

2、为什么不能让前端传用户 ID？#

有些新人可能会想：前端直接把用户 ID 传过来不就行了？

1
// ❌ 错误做法：让前端传 userId
2
@PostMapping("/add")
3
public Result add(@RequestParam Long userId, @RequestBody Order order) {
4
    order.setCreateBy(userId);  // 前端传过来的 userId
5
    orderService.save(order);
6
    return Result.success();
7
}

这存在严重的安全问题：

如果有人用 Postman 之类的工具直接调用接口，把 userId 改成别人的，就能以别人的身份创建数据。这等于说，谁都能冒充任何人操作。

所以，当前用户的身份必须从后端的认证信息中获取，不能依赖前端传递。

正确的做法是：

1
// ✅ 正确做法：从后端的认证上下文中获取当前用户
2
@PostMapping("/add")
3
public Result add(@RequestBody Order order) {
4
    Long userId = SecurityUtils.getUserId();  // 从后端获取，而非前端传入
5
    order.setCreateBy(userId);
6
    orderService.save(order);
7
    return Result.success();
8
}

3、真实工作中一般获取登录用户的代码#

以下均是真实工作中项目代码截图。从这些代码可以看出，这种获取登录用户的逻辑都是封装到工具类里面的。

4、一般都是怎么实现的？#

不同登录认证方式，获取用户的实现也有所不同。但一般思路知道即可，真实工作中需要你写的可能性极低，即使让你写，也可以让 AI 直接帮你写。

一般思路如下：

拦截请求 → 解析凭证 → 存储当前用户 → 后续随时获取用户信息

1）、拦截请求

请求到达后端后，会先经过全局拦截器（Filter / Interceptor）。它会检查请求中是否携带了 Token、Session ID 等登录凭证。

2）、解析用户信息

• 如果是 JWT Token： 后端会解析 Token，拿到 userId 等用户信息，必要时再去 Redis 查询完整用户数据。
• 如果是 Session： 后端会根据 Session ID，从 Tomcat 或 Redis 中取出对应的用户对象。

3）、存入当前线程（ThreadLocal）

拿到用户信息后，框架会把当前用户存入 ThreadLocal（例如 Spring Security 的 SecurityContext）。

这样后续业务代码中，就不需要层层传递用户参数了。在 Controller、Service 里直接调用类似：

1
SecurityUtils.getUser()

底层其实就是从 ThreadLocal 中获取当前登录用户。

4）、真实项目中常见的获取用户方式（了解）

上面讲的是一般思路，下面是真实项目中的统计，帮你了解实际工作中会遇到哪些方式。

常见方式统计

实际工作中怎么快速上手？

1. 找到项目里获取用户的方式：搜索 SecurityUtils、getLoginUser、getCurrentUser 等关键词
2. 直接使用：找到后直接用，不用关心底层实现，项目里别人怎么写，你就怎么写
3. 不要自己造轮子：项目里一般都有现成的工具类，直接调用即可

总结：入职后不需要从头实现获取用户的逻辑，找到项目里现有的方式直接用就行。如果找不到，先问 AI 帮你搜，搜不到再问同事。

1、RBAC 权限模型#

RBAC（Role-Based Access Control，基于角色的访问控制）是企业中最常见的权限模型。

核心思路

1
用户 → 角色 → 权限

也就是说：

• 一个用户可以拥有多个角色
• 一个角色可以拥有多个权限
• 一个权限对应一个具体的操作（如：用户列表查询、用户删除等）

数据库设计通常是这几张表

举例

1
用户：张三
2
        ↓
3
角色：普通管理员
4
        ↓
5
权限：用户列表查询、用户详情查询、用户编辑
6
（没有"用户删除"权限）
7
        ↓
8
张三可以查看和编辑用户，但不能删除用户

2、权限控制的常见实现方式#

其中，接口级权限 是后端开发最常接触的。

3、为什么要前后端都做权限控制？#

有些同学可能会想：前端已经根据权限隐藏了按钮，后端还需要再校验吗？

答案是：必须的。

因为前端隐藏按钮只是页面展示层面的控制，用户完全可以通过直接调用接口来绕过前端限制。所以：

前端权限控制是为了用户体验，后端权限控制是为了安全。

1、权限控制#

若依的权限控制是基于 RBAC 模型 实现的，涉及以下几张核心表：

接口级权限

若依使用 Spring Security 的 @PreAuthorize 注解来控制接口权限：

按权限字符控制：判断当前用户是否拥有指定权限字符串

1
@PreAuthorize("@ss.hasPermi('system:user:list')")
2
@GetMapping("/list")
3
public TableDataInfo list(SysUser user) {
4
    // ...
5
}

@ss 是若依自定义的权限服务 PermissionService，注册为 Spring Bean，名称为 ss。hasPermi 方法会从当前登录用户的权限列表中判断是否包含指定的权限字符串。

1
// PermissionService.java — 权限判断的核心逻辑
2
@Service("ss")  // 注册为Spring Bean，名称为ss
3
public class PermissionService {
4

5
    public boolean hasPermi(String permission) {
6
        LoginUser loginUser = SecurityUtils.getLoginUser();
7
        if (StringUtils.isNull(loginUser) || CollectionUtils.isEmpty(loginUser.getPermissions())) {
8
            return false;
9
        }
10
        // 判断用户的权限列表中是否包含该权限
11
        return hasPermissions(loginUser.getPermissions(), permission);
12
    }
13

14
    // 支持任意一个权限匹配
15
    public boolean hasAnyPermi(String permissions) {
16
        // 多个权限用逗号分隔，只要有一个匹配就返回true
17
    }
18

19
    // 判断是否拥有某个角色
20
    public boolean hasRole(String role) {
21
        // 从用户的角色列表中判断
22
    }
23

24
    // 支持任意一个角色匹配
25
    public boolean hasAnyRoles(String roles) {
26
        // 多个角色用逗号分隔，只要有一个匹配就返回true
27
    }
28
}

按角色控制：判断当前用户是否拥有指定角色

1
// 判断是否拥有 admin 角色
2
@PreAuthorize("@ss.hasRole('admin')")
3
@GetMapping("/list")
4
public TableDataInfo list(SysUser user) {
5
    // ...
6
}
7

8
// 判断是否拥有任意一个角色（admin 或 common）
9
@PreAuthorize("@ss.hasAnyRoles('admin,common')")
10
@GetMapping("/list")
11
public TableDataInfo list(SysUser user) {
12
    // ...
13
}

按钮级权限

前端使用自定义指令 v-hasPermi 来控制按钮是否显示：

1
<!-- 只有拥有 system:user:add 权限的用户才能看到"新增"按钮 -->
2
<el-button v-hasPermi="['system:user:add']">新增</el-button>
3
<el-button v-hasPermi="['system:user:edit']">修改</el-button>
4
<el-button v-hasPermi="['system:user:remove']">删除</el-button>
5

6
<!-- 需要同时拥有多个权限中的任意一个 -->
7
<el-dropdown v-hasPermi="['system:user:resetPwd', 'system:user:edit']">
8
    <el-button>更多操作</el-button>
9
</el-dropdown>

v-hasPermi 指令的判断逻辑：

1
export default {
2
  inserted(el, binding) {
3
    const { value } = binding                                    // 按钮上写的权限标识，如 ['system:user:add']
4
    const permissions = store.getters.permissions               // 用户拥有的权限列表（从 /getInfo 接口获取）
5

6
    const hasPermissions = permissions.some(permission => {
7
      return "*:*:*" === permission                              // 超级管理员有所有权限
8
        || value.includes(permission)                            // 或者用户权限列表中包含这个标识
9
    })
10

11
    if (!hasPermissions) {
12
      el.parentNode && el.parentNode.removeChild(el)            // 没权限就从页面移除按钮
13
    }
14
  }
15
}

数据权限

前面的接口级权限和按钮级权限解决的是”你能不能调这个接口”的问题，而数据权限解决的是”你能看到哪些数据”的问题。

同样是”用户列表”接口，部门经理能看到本部门所有员工的数据，普通员工只能看到自己的数据。

若依的数据权限是通过 AOP + MyBatis 参数注入 实现的，核心思路就是在查询 SQL 中动态拼接 WHERE 条件。

1）数据权限的五个等级

每个角色都有一个 dataScope 字段，对应 sys_role 表的 data_scope 列：

2）怎么使用

只需在 Service 方法上加 @DataScope 注解：

1
@DataScope(deptAlias = "d", userAlias = "u")
2
public List<SysUser> selectUserList(SysUser user)
3
{
4
    return userMapper.selectUserList(user);
5
}

然后在 MyBatis XML 的查询 SQL 末尾加上 ${params.dataScope}：

1
<select id="selectUserList" parameterType="SysUser" resultMap="SysUserResult">
2
    select u.user_id, u.dept_id, u.user_name, d.dept_name
3
    from sys_user u
4
    left join sys_dept d on u.dept_id = d.dept_id
5
    where u.del_flag = '0'
6
    ${params.dataScope}
7
</select>

3）运行原理

AOP 切面（DataScopeAspect）会在方法执行前拦截，获取当前用户的所有角色，根据每个角色的 dataScope 值生成对应的 SQL 过滤条件，注入到方法参数的 params.dataScope 中。这样 MyBatis 执行时就会自动拼接上数据权限的过滤条件。

简单来说：加个 @DataScope 注解 + XML 里写个 ${params.dataScope}，数据权限就生效了。

注意：正常业务开发中应谨慎使用 ${}，因为它会直接进行字符串拼接，存在 SQL 注入风险（应优先使用 #{}）。若依的数据权限实现中，拼接内容由 AOP 切面根据用户角色自动生成，来源可控，因此能够安全使用。不要在其他业务场景中模仿这种写法，除非你能确保拼接内容的安全性。

2、其他权限控制方式#

上面介绍的若依是典型的 RBAC 权限模型，适合角色多、权限细的场景。但有些项目可能并不需要那么精细的权限控制，只需要区分”管理员”和”普通用户”，这种情况下往往直接在代码里加一层判断就行了。

1
-- user 表中加一个 role 字段
2
CREATE TABLE user (
3
    id BIGINT PRIMARY KEY,
4
    username VARCHAR(50),
5
    password VARCHAR(100),
6
    role VARCHAR(20) DEFAULT 'user'  -- admin 表示管理员，user 表示普通用户
7
);

1
@GetMapping("/admin/users")
2
public Result getUserList() {
3
    User currentUser = SecurityUtils.getCurrentUser();
4
    if (!"admin".equals(currentUser.getRole())) {
5
        return Result.error(403, "无权限访问");
6
    }
7
    // 管理员才能执行的逻辑
8
    return Result.success(userService.list());
9
}

1
@GetMapping("/admin/users")
2
public Result getUserList() {
3
    checkAdmin();  // 公共方法，不是管理员直接抛异常
4
    return Result.success(userService.list());
5
}
6

7
private void checkAdmin() {
8
    User currentUser = SecurityUtils.getCurrentUser();
9
    if (!"admin".equals(currentUser.getRole())) {
10
        throw new BusinessException("无权限访问");
11
    }
12
}

1
@Component
2
public class AdminInterceptor implements HandlerInterceptor {
3

4
    @Override
5
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
6
        String uri = request.getRequestURI();
7
        // 只拦截 /admin/** 路径下的接口
8
        if (uri.startsWith("/admin/")) {
9
            User currentUser = SecurityUtils.getCurrentUser();
10
            if (!"admin".equals(currentUser.getRole())) {
11
                response.setStatus(403);
12
                return false;
13
            }
14
        }
15
        return true;
16
    }
17
}

1
@Configuration
2
public class WebMvcConfig implements WebMvcConfigurer {
3

4
    @Autowired
5
    private AdminInterceptor adminInterceptor;
6

7
    @Override
8
    public void addInterceptors(InterceptorRegistry registry) {
9
        registry.addInterceptor(adminInterceptor)
10
                .addPathPatterns("/admin/**");
11
    }
12
}

1
// 定义注解
2
@Target(ElementType.METHOD)
3
@Retention(RetentionPolicy.RUNTIME)
4
public @interface RequireAdmin {
5
}
6

7
// 在需要管理员权限的接口上加注解
8
@RequireAdmin
9
@GetMapping("/users")
10
public Result getUserList() {
11
    return Result.success(userService.list());
12
}

1
@Aspect
2
@Component
3
public class AdminAspect {
4

5
    @Before("@annotation(requireAdmin)")
6
    public void checkAdmin(RequireAdmin requireAdmin) {
7
        User currentUser = SecurityUtils.getCurrentUser();
8
        if (!"admin".equals(currentUser.getRole())) {
9
            throw new BusinessException("无权限访问");
10
        }
11
    }
12
}

1
// 根据用户角色控制页面元素的显示
2
if (user.role === 'admin') {
3
    // 显示管理后台入口、用户管理菜单等
4
    showAdminMenu();
5
} else {
6
    // 隐藏这些元素
7
    hideAdminMenu();
8
}

1、什么是跨域？跨域和鉴权有什么关系？#

同源策略是浏览器的安全机制：只有当请求的协议、域名、端口三者都相同时，才被认为是”同源”。不满足任一条件就是”跨域”。

例如，前端在 http://localhost:3000，后端在 http://localhost:8080，端口不同，就是跨域。

跨域对鉴权的影响：

• Cookie 方式：默认情况下，跨域请求不会携带 Cookie，需要后端配置 CORS 并设置 Access-Control-Allow-Credentials: true
• Token 方式：前端手动在请求头中添加 Token，不受 Cookie 限制，但需要后端配置 CORS 允许自定义请求头

后端解决跨域的常见方式：

1
// 方式一：在 Controller 或方法上加注解
2
@CrossOrigin(origins = "http://localhost:3000")
3

4
// 方式二：全局配置
5
@Configuration
6
public class CorsConfig implements WebMvcConfigurer {
7
    @Override
8
    public void addCorsMappings(CorsRegistry registry) {
9
        registry.addMapping("/**")
10
                .allowedOrigins("http://localhost:3000")
11
                .allowedMethods("*")
12
                .allowCredentials(true);
13
    }
14
}

2、什么是 OAuth 2.0？它和 JWT 什么区别？#

OAuth 2.0 是什么？

OAuth 2.0 是一个授权框架，它解决的核心问题是：

如何让用户在不给第三方应用密码的情况下，授权它访问自己的资源。

最常见的场景就是”第三方登录”，比如：

• 用微信扫码登录某个网站
• 用 GitHub 账号登录某个开发工具
• 用 Google 账号登录某个 App

OAuth 2.0 和 JWT 的区别

这两个东西经常被混淆，但它们根本不在同一层：

简单来说：OAuth 2.0 定义的是”流程”，JWT 定义的是”格式”。 OAuth 2.0 流程中产生的 Token 可以用 JWT 格式，也可以不用。

作为后端开发，你更常接触的是 JWT。OAuth 2.0 一般在对接第三方登录时才会用到，而且通常已经有现成的 SDK 或框架集成，不需要你自己从头实现。

3、SSO 是什么？#

SSO（Single Sign-On，单点登录）解决的问题是：

用户在多个系统中只需要登录一次，就能访问所有互相信任的系统，不需要重复登录。

举个例子：

1
你们公司有以下系统：
2
    - OA 系统（oa.company.com）
3
    - HR 系统（hr.company.com）
4
    - 邮件系统（mail.company.com）
5

6
没有 SSO 的情况：
7
    - 你要先登录 OA → 输入一次账号密码
8
    - 再登录 HR → 再输入一次账号密码
9
    - 再登录邮件 → 又输入一次账号密码
10

11
有了 SSO：
12
    - 你只要登录一次（比如先登录 OA）
13
    - 然后访问 HR、邮件系统，都自动识别你已登录，不需要再输入密码

SSO 的核心思路

1
用户访问系统 A
2
        ↓
3
系统 A 发现用户没登录，跳转到 SSO 认证中心
4
        ↓
5
用户在认证中心输入账号密码，登录成功
6
        ↓
7
认证中心给用户发一个全局凭证（Ticket / Token），同时记录"这个用户已经登录了"
8
        ↓
9
用户带着凭证回到系统 A，系统 A 拿凭证去认证中心验证，验证通过，登录成功
10
        ↓
11
用户再访问系统 B
12
        ↓
13
系统 B 发现用户没登录，跳转到认证中心
14
        ↓
15
认证中心发现这个用户已经登录过了（不需要再输密码），直接给用户发凭证
16
        ↓
17
用户带着凭证回到系统 B，登录成功

常见实现方式

入职后你大概率会遇到 SSO，因为只要公司有多个内部系统，基本都会做单点登录。不过 SSO 的实现一般也是现成的，你不需要从零写，了解即可。

4、如何放行某个接口，不需要登录即可访问？#

系统里不是所有接口都需要登录才能访问。有些接口天然就不需要鉴权，如果不放行，功能就会出问题。常见的放行场景如下：

想要知道你们项目怎么放行接口的，就全局搜索登录接口，去看它怎么放行的，或者也可以让 AI 告诉你。

常见的放行方式有以下几种：

方式一：在拦截器配置中排除路径

这是最直接的方式，在拦截器注册时指定哪些路径不需要拦截：

1
@Configuration
2
public class WebMvcConfig implements WebMvcConfigurer {
3

4
    @Autowired
5
    private AuthInterceptor authInterceptor;
6

7
    @Override
8
    public void addInterceptors(InterceptorRegistry registry) {
9
        registry.addInterceptor(authInterceptor)
10
                .addPathPatterns("/**")                          // 拦截所有请求
11
                .excludePathPatterns(                            // 排除以下路径，不做鉴权
12
                        "/login",
13
                        "/register",
14
                        "/captcha",
15
                        "/public/**"
16
                );
17
    }
18
}

方式二：在 Security 配置中放行

如果项目用的是 Spring Security，可以在安全配置类中放行：

1
@Configuration
2
@EnableWebSecurity
3
public class SecurityConfig {
4

5
    @Bean
6
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
7
        http.authorizeHttpRequests(auth -> auth
8
                .requestMatchers("/login", "/register", "/captcha", "/public/**").permitAll()  // 放行
9
                .anyRequest().authenticated()  // 其他请求需要认证
10
        );
11
        return http.build();
12
    }
13
}

方式三：用自定义注解标记放行接口

有些项目会定义一个 @Anonymous 注解，加在接口上就表示不需要登录：

1
// 定义注解
2
@Target({ElementType.METHOD, ElementType.TYPE})
3
@Retention(RetentionPolicy.RUNTIME)
4
public @interface Anonymous {
5
}
6

7
// 在不需要登录的接口上加注解
8
@Anonymous
9
@GetMapping("/public/article/{id}")
10
public Result getArticle(@PathVariable Long id) {
11
    return Result.success(articleService.getById(id));
12
}

然后在拦截器中判断：如果接口方法上有 @Anonymous 注解，就直接放行：

1
@Override
2
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
3
    // 如果是带有 @Anonymous 注解的接口，直接放行
4
    if (handler instanceof HandlerMethod handlerMethod) {
5
        Anonymous anonymous = handlerMethod.getMethodAnnotation(Anonymous.class);
6
        if (anonymous != null) {
7
            return true;
8
        }
9
    }
10
    // 其他接口正常做鉴权校验
11
    // ...
12
}

方式三的好处：放行配置直接写在接口上，一目了然，不用跑到配置类里去找。若依框架就是用的这种注解方式（@Anonymous）来放行接口的。

5、常见鉴权问题排查#

实际工作中，以下是最常见的鉴权相关问题及排查思路。

实用排查技巧：参考平台其他接口的传参方式

如果不确定某个接口的认证参数怎么传，可以先登录你们公司的平台，按 F12 打开浏览器开发者工具，切换到 Network（网络）面板，然后在页面上随便操作一下，观察其他接口是怎么传 Token/Cookie 的——请求头叫什么名字、格式是什么（比如 Bearer xxx 还是直接传值）。照着别的接口的传参方式来就行，这是最快的方式，比自己猜或者翻代码都快。

1
// 在主线程中先获取当前用户
2
Long userId = SecurityUtils.getUserId();
3

4
// 把 userId 作为参数传给异步方法，不要在异步方法里面再去调 SecurityUtils.getUserId()
5
@Async
6
public void doSomething(Long userId) {
7
    // 这里直接用传进来的 userId，不要再去获取当前登录用户
8
}