17370845950

Token鉴权通过“登录换凭证、后续带证校验”实现身份确认与权限控制；后端验证账号密码后生成JWT格式token并返回，前端在Authorization头中携带，后端验签、检过期、查权限，失败则返回401；采用短效Access Token配长效Refresh Token机制实现安全与体验平衡。

接口鉴权用 token 是为了确认调用者身份、控制访问权限，避免未授权操作。核心是“发一次登录换凭证，后续请求带凭证校验”，不是每次都要输账号密码。

token 怎么生成和下发

用户用账号密码发起登录请求（比如 POST /api/login），后端验证通过后，生成一个加密字符串（即 token），通常用 JWT 格式。它内部包含用户 ID、过期时间、签发时间等信息，并用密钥签名防篡改。服务端不存 token 本体（无状态设计），只返回给前端，例如：

• 响应头中加 Authorization: Bearer eyJhbGciOi...
• 或响应体里返回 {"token": "eyJhbGciOi..."}

前端怎么传 token

后续所有需鉴权的接口，前端必须在请求头带上 token，标准写法是：

• Authorization: Bearer {token值}（最常用，推荐）
• 少数老系统可能用自定义头，如 X-Auth-Token: {token值}
• 不建议放 URL 参数或 request body，有泄露风险

后端怎么校验 token

收到请求后，后端从请求头提取 token，做三件事：

• 解析 JWT，检查签名是否合法（用相同密钥验签）
• 读取 payload，确认 exp（过期时间） 未到、iat（签发时间） 合理
• 根据用户 ID 查数据库或缓存，确认账号是否启用、权限是否有效（如被禁用或角色变更）

任一环节失败，就返回 401 Unauthorized。

token 过期和刷新机制

短期 token（如 2 小时）安全但体验差；长期 token（如 7 天）方便但风险高。常见折中方案是配一对 token：

• Access Token：短期有效（如 30 分钟），用于日常接口调用
• Refresh Token：长期有效（如 7 天），仅用于换取新 Access Token，且用完即废、绑定设备/IP

前端检测到 401 时，拿 Refresh Token 请求 /api/refresh 接口，成功则更新 Access Token 继续后续请求。