token如何生成和验证：基于密钥加密签名实现可信身份校验

之前做后端接口鉴权开发的时候，一直摸不透token如何生成和验证，网上的理论讲解太笼统，落地实操全是bug，只能自己一遍遍调试代码、排查问题，实打实踩坑摸清了整套可直接用的实操流程。

最开始踩的最大误区，以为token是系统随机生成的乱码。

第一次自己写生成逻辑，随手写了一段随机字符串代码，简单拼接上用户ID、登录时间和过期时长，就当成有效token给到前端。本地测试看着一切正常，一上线就彻底乱套，用户频繁出现鉴权失效、无故退出登录的情况，偶尔还能通过篡改参数登录他人账号。熬了大半个晚上逐行排查代码，才幡然醒悟，纯随机生成的字符没有任何校验锚点，后端没有任何依据辨别token的真伪，不管是篡改内容还是伪造新字符串，系统都无法识别，这种敷衍的生成方式，完全达不到身份鉴权的作用。

后来才反应过来，主流可用的token生成，核心全靠密钥加密签名。我日常实操用的是最通用的JWT格式，生成步骤特别固定，没有复杂套路。先配置好专属的加密密钥和加密算法，再把用户唯一标识、权限信息、凭证过期时间打包成载荷数据，接着用预设密钥和算法对头部、载荷数据进行加密，生成专属数字签名，最后将头部、载荷、签名三段内容拼接起来，就是完整、有效的token凭证。

生成的核心底线，就是密钥绝对不能外泄。

密钥一旦泄露，任何人都能复刻加密逻辑、伪造合法token，整套鉴权体系直接作废。我之前团队有新人图方便，把密钥直接写在前端静态文件里，上线半天就出现了批量伪造登录的问题，那次事故也让我记住，密钥必须存放在后端服务，绝对不对外暴露。

折腾好久才搞明白，token验证的逻辑和我最初的认知完全相反，根本不是解密查看内容是否正常。最开始做验证逻辑时，一直靠解密token读取用户信息，只要数据能正常解析，就判定验证通过，这种做法完全是自欺欺人，篡改载荷里的用户信息后，解密依旧能成功，鉴权等于形同虚设。

真正的验证流程特别严谨，全程围绕签名比对展开。后端接收前端传回的token后，先拆分出头部、载荷、签名三个独立部分，调用和生成token时完全一致的算法与密钥，重新对头部和载荷计算出新的数字签名，将新签名和token自带的原始签名逐一比对。同时校验载荷内的过期时间，只要签名不匹配、或是凭证超时，直接驳回鉴权请求，只有两项校验全部通过，才判定token有效。

实操里还有个很关键的细节，生成token的密钥不能用简单短字符。试过6位数字字母组合的短密钥，很容易被暴力破解，换成32位含特殊符号的复杂密钥后，安全性提升了不止一个档次，也是实操中最没必要省略的步骤。

调试通整套生成和验证逻辑的那晚，删掉所有错误代码，运行成功的那一刻，电脑屏幕的代码亮光映在桌面上，整个人终于不用再反复重启服务测试了。