认证令牌是怎么来的
平时登录一个网站或App，比如网购平台、银行应用，输完账号密码后，系统不会每次都让你重新登录。背后起作用的就是认证令牌（Authentication Token）。它像一张临时通行证，证明你已经通过验证，可以正常访问资源。
那这张“通行证”是怎么生成的？很多人遇到登录失效、接口报错401，问题就出在令牌生成或传递环节。
令牌生成的基本流程
当用户输入正确的用户名和密码，服务器确认身份无误后，会进入令牌生成阶段。最常见的实现方式是JWT（JSON Web Token），结构清晰，自包含信息。
JWT由三部分组成：头部（Header）、载荷（Payload）、签名（Signature），用点号.连接：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c第一段是头部，说明加密算法和类型；第二段是载荷，包含用户ID、过期时间等信息；第三段是签名，防止数据被篡改。
签名是如何保证安全的
签名不是随便生成的，服务器会把前两段拼起来，再用一个密钥（secret key）进行哈希运算，常用的是HMAC SHA256。只有持有相同密钥的服务端才能验证这个签名是否有效。
比如Node.js里用jsonwebtoken库生成令牌：
const jwt = require('jsonwebtoken');
const token = jwt.sign({ userId: '123', role: 'user' }, 'your-secret-key', { expiresIn: '2h' });这里设了两小时过期，避免长期有效带来的风险。如果客户端拿一个过期的令牌请求接口，自然会被拒绝，表现为“登录状态丢失”。
常见故障场景
有次后台接口突然大面积返回401，排查发现是运维更新服务时，把签发令牌的密钥改了，但旧令牌还没过期。新服务验不了旧签名，直接拒掉，用户全被踢下线。这就是典型的密钥不一致问题。
还有一种情况是前端传令牌时格式不对。标准做法是放在HTTP请求头Authorization字段里，写成Bearer开头：
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...如果前端漏了Bearer，或者把令牌拼在URL参数里传输，后端拿不到正确值，也会认证失败。
时间不同步也会引发问题。JWT里的过期时间依赖系统时钟。如果服务器时间比实际快了半小时，用户刚拿到的令牌可能瞬间就失效。这类问题在虚拟机或容器时间配置错误时经常出现。
调试建议
遇到认证失败，先看浏览器开发者工具的Network面板，找到请求头有没有带上令牌，格式对不对。再检查响应体是否明确提示token expired或invalid signature。
用在线JWT解码工具粘贴令牌，能直接看到里面的时间和用户信息，判断是不是过期或内容异常。别忘了核对服务端日志，确认密钥配置和服务时间是否正常。