Sa-Token 自定义 Token 请求格式：为什么要使用 Authorization Bearer

在前后端分离项目中，用户登录成功后，通常会拿到一个 Token。

后续请求需要把 Token 携带给后端，后端才能判断当前用户是否已经登录。

Sa-Token 默认可以通过类似下面的方式携带 Token：

satoken: xxxxx

但是在很多项目中，更常见的写法是：

Authorization: Bearer xxxxx

因此，我们可以对 Sa-Token 的 Token 请求格式进行自定义。

一、这是在干什么？

简单来说：

把 Sa-Token 默认的 Token 请求格式，修改成 Authorization: Bearer Token值。

例如用户登录后得到：

abc123456

以前请求时可能这样携带：

satoken: abc123456

修改配置后，需要这样携带：

Authorization: Bearer abc123456

Token 本身并没有变化。

变化的只是：

Token 放在哪个请求头，以及 Token 前面是否需要添加前缀。

二、为什么要这样做？

主要是为了让 Token 请求格式更加统一。

很多前后端项目都会采用：

Authorization: Bearer xxx

这种格式。

它的好处是：

请求格式更加统一
前后端约定更加清晰
Gateway 更方便统一读取 Token
和很多常见接口认证方式保持一致

因此，在实际项目中，通常会把 Token 统一放到 Authorization 请求头中。

三、如何实现？

Sa-Token 提供了两个配置：

sa-token:
  token-name: Authorization
  token-prefix: Bearer

其中：

token-name

token-name: Authorization

表示：

Sa-Token 从 Authorization 请求头中读取 Token。

配置以后，就不会再按照原来的 satoken 请求头读取。

token-prefix

token-prefix: Bearer

表示：

Token 前面必须携带 Bearer 前缀。

因此最终请求格式就是：

Authorization: Bearer Token值

注意：

Bearer 和 Token 中间需要有一个空格。

四、Gateway 是如何校验的？

客户端发送请求：

Authorization: Bearer abc123

请求先进入 Gateway。

Gateway 中的 Sa-Token 会读取：

Authorization

然后识别：

Bearer abc123

最终拿到真正的 Token：

abc123

再根据 Token 判断当前用户是否已经登录。

整个流程可以理解成：

客户端请求
    ↓
Authorization: Bearer Token
    ↓
Gateway
    ↓
Sa-Token 获取 Token
    ↓
判断登录状态
    ↓
有效 → 放行
无效 → 拦截

五、为什么认证服务和 Gateway 都要配置？

在微服务项目中：

认证服务

主要负责用户登录以及 Token 相关处理。

而：

Gateway

负责在请求进入微服务之前进行登录校验。

因此两边的 Token 规则需要保持一致。

例如都约定：

Authorization: Bearer xxx

如果认证服务使用 Authorization，而 Gateway 还在读取 satoken，就会出现 Token 明明存在，但 Gateway 识别不到的问题。

所以通常需要让认证服务和 Gateway 使用相同的 Sa-Token 配置。

六、总结

这一节做的事情其实非常简单：

将 Sa-Token 的 Token 请求格式统一修改为 Authorization: Bearer Token值。

主要配置就是：

token-name: Authorization
token-prefix: Bearer

最终请求格式：

Authorization: Bearer xxx

可以简单记成：

Authorization 决定 Token 放在哪里，Bearer 决定 Token 前面的格式。

这样整个系统的 Token 请求规范就统一了。