后端基础-认证与登录

目录

• 第1章 认证与授权
  • 1.1 认证
  • 1.2 授权
  • 1.3 登录
• 第2章 登录态
  • 2.1 Session
  • 2.2 Token
  • 2.3 Session 与 JWT
  • 2.4 Cookie 与 Authorization
• 第3章 JWT
  • 3.1 JWT
  • 3.2 payload
  • 3.3 sub
  • 3.4 exp
  • 3.5 SECRET_KEY
  • 3.6 algorithm
  • 3.7 Bearer Token
• 第4章 登录方式
  • 4.1 短信登录
  • 4.2 验证码存储
  • 4.3 防刷
• 第5章 权限与风险
  • 5.1 权限
  • 5.2 常见风险

第1章 认证与授权

1.1 认证

• 认证 Authentication：确认“你是谁”。
• 认证回答的是身份问题，不回答权限问题。

1.2 授权

• 授权 Authorization：确认“你能做什么”。
• 授权发生在“已识别用户身份”之后。

1.3 登录

• 登录是“建立身份”的业务流程。
• 登录成功后，服务端需要给客户端一个可持续识别用户的凭据。

第2章 登录态

2.1 Session

• Session 是服务端保存的会话状态。
• 浏览器通常只保存 Session ID，真正的会话数据保存在服务端。

常见链路：

1. 用户登录成功
2. 服务端创建 Session
3. 服务端通过 Set-Cookie 下发 Session ID
4. 浏览器后续请求自动带上 Cookie
5. 服务端根据 Session ID 找到对应会话

2.2 Token

• Token 是服务端签发给客户端的一段凭据。
• 客户端后续请求通常通过 Authorization 请求头携带 Token。

Authorization: Bearer <token>

• Token 方案常见于前后端分离、移动端、开放接口。

2.3 Session 与 JWT

• Session：状态保存在服务端，便于主动失效
• JWT：状态更多体现在客户端持有的令牌，横向扩展更方便
• 没有绝对更优，取决于系统边界和风格

2.4 Cookie 与 Authorization

• Cookie 是浏览器自动携带机制。
• Authorization 是显式请求头，常由前端代码主动附加。
• Session 常和 Cookie 搭配，JWT 常和 Authorization 搭配。

第3章 JWT

3.1 JWT

• JWT 是一种 Token 格式，不等于所有 Token。
• JWT 通常由三段组成：头部、载荷、签名。

结构上可以近似理解成：

header.payload.signature

• header：声明签名算法等元信息

• payload：承载身份声明数据

• signature：基于密钥和算法算出的签名

• 服务端校验签名后，可以确认内容没有被篡改。

• JWT 适合表达身份声明，不适合放敏感明文数据。

• JWT 一旦签发，撤销通常比 Session 更麻烦。

3.2 payload

• payload 是写进 JWT 的数据字典。
• 它承载的是“这张 token 要表达什么身份声明”。

常见最小示例：

{
  "sub": "study_user",
  "exp": 1740000000
}

3.3 sub

• sub = subject。
• 表示“这个 token 属于谁”。
• 常见写法是放用户名、用户 ID 或其他稳定用户标识。

3.4 exp

• exp = expiration time。
• 表示“这个 token 到什么时候过期”。
• 服务端校验 token 时，如果当前时间超过 exp，就应判定 token 失效。

3.5 SECRET_KEY

• SECRET_KEY 是服务端用于签名和验签的私密密钥。
• 它不是登录密码，也不是用来隐藏 payload 内容的字段。
• 它的主要作用是防止客户端伪造或篡改 token。

如果 SECRET_KEY 泄露，别人就可能伪造合法 token。

3.6 algorithm

• algorithm 是 JWT 的签名算法名。
• 常见如：
  • HS256
  • HS384
  • HS512

当前很多单体服务或教学项目会先用 HS256。

• HS256 表示使用 HMAC-SHA256
• 生成 token 和校验 token 都依赖同一个 SECRET_KEY

3.7 Bearer Token

• Bearer Token 指“谁持有谁可用”的访问令牌。
• 后续请求通常放在：

Authorization: Bearer <token>

• 服务端会先提取 token，再验证签名、过期时间和用户身份。

第4章 登录方式

4.1 短信登录

• 短信登录是验证码登录的一种实现。
• 核心不是短信，而是“一次性验证码校验 + 登录态签发”。

常见流程：

1. 用户提交手机号
2. 服务端生成验证码
3. 服务端把验证码写入缓存并设置过期时间
4. 短信服务商发送验证码
5. 用户提交手机号和验证码
6. 服务端校验验证码
7. 校验通过后签发 Session 或 Token

4.2 验证码存储

• 验证码通常放 Redis 这类带过期能力的存储。
• 键一般和手机号、业务场景绑定。
• 验证通过后应立即失效，避免重复使用。

4.3 防刷

• 短信登录必须做频率限制。
• 常见限制维度：
  • 单手机号发送频率
  • 单 IP 请求频率
  • 单设备请求频率
• 还需要限制验证码尝试次数，避免暴力猜测。

第5章 权限与风险

5.1 权限

• 权限校验发生在“已识别用户身份”之后。
• 常见权限粒度：
  • 是否登录
  • 角色
  • 资源归属
  • 操作范围

示例：

• 普通用户只能修改自己的资料
• 管理员可以查看全部用户

5.2 常见风险

• 把敏感信息直接放进 JWT 载荷
• SECRET_KEY 过短或泄露
• token 没有过期时间
• 验证码不过期
• 验证通过后验证码仍可重复使用
• 登录接口没有限流
• 只做前端权限判断，不做后端权限校验

关联

• Cookie、Header、状态码位置：后端基础-HTTP与请求响应
• 接口文档如何声明鉴权要求：后端基础-API设计与OpenAPI