JWT秘钥如何做？聊聊我踩过的那些坑和最终方案
大家好呀,我是你们的老朋友，一个在后台摸爬滚打了好几年的程序员，今天想跟大家唠唠一个看似简单、但真做起来能让人头秃的话题——JWT秘钥如何做。
说实话,我第一次接触JWT的时候，觉得这玩意儿挺香啊，无状态、跨域友好、还能塞点用户信息进去，结果一到“秘钥怎么搞”这一步，直接懵了，网上搜一圈，答案五花八门：有人让你直接写个字符串，有人让你用HS256随便生成一个，还有人神神秘秘地说“用RS256更安全”……到底听谁的？别急，我把我踩过的坑和最后总结出来的方案，一股脑儿分享给你。
先说最low的做法：硬编码一个字符串
刚入门那会儿,我干过这种事：
SECRET_KEY = "mysecretkey123"
对,就这么简单粗暴，跑起来确实没问题，JWT签发、验证都正常，但兄弟，这玩意儿能上线吗？绝对不能啊！ 你想想，秘钥写死在代码里，一旦代码泄露（比如传到GitHub公开仓库），别人就能随便伪造token，冒充任何用户，我当年差点因为这个被老大骂死，现在想起来还后怕。
所以啊,JWT秘钥如何做的第一步，永远不要把秘钥硬编码在代码里！
那用环境变量？好一点，但还不够
后来我学乖了,把秘钥放到环境变量里：
export JWT_SECRET="a-long-random-string"
然后在代码里读取,嗯，这确实比硬编码强多了，但问题来了——秘钥怎么生成？很多人随手敲个“abc123”就完事了，这跟没设一样。JWT秘钥必须足够随机、足够长。 我一般用OpenSSL生成：
openssl rand -base64 64
这样出来的字符串,暴力破解基本没戏，不过环境变量也有坑：如果服务器被入侵，环境变量照样能被读到，所以啊，JWT秘钥如何做这件事，得看你的安全等级要求。
更靠谱的方案：非对称加密（RS256）
如果你问我生产环境推荐啥,我绝对拍桌子说：用RS256！ 为啥？因为对称加密（HS256）只有一个秘钥，签发和验证都用它，万一某个服务只需要验证token，你却把秘钥给了它，那它就能伪造token了，这风险多大呀！
RS256就不一样了,它有一对钥匙：私钥签名，公钥验证，私钥只有认证服务器有，公钥可以随便分发，这样一来，即使公钥泄露，别人也伪造不了token，那JWT秘钥如何做呢？生成一对RSA密钥就行：
openssl genrsa -out private.pem 2048 openssl rsa -in private.pem -pubout -out public.pem
私钥藏好,公钥随便给，是不是很优雅？不过RS256也有缺点：签名和验证比HS256慢一些，token也会长一点，但为了安全，这点性能损失算啥呀！
秘钥轮换：别忘了这个骚操作
你以为选好算法就完事了？太天真啦！JWT秘钥如何做还有一个关键点：定期轮换，为啥？万一秘钥不小心泄露了，你总不能一直用下去吧？轮换的意思是，过一段时间换一个新秘钥，旧token要么过期，要么用旧秘钥验证到过期为止。
我一般这么做：维护一个秘钥列表，每个秘钥有个ID（kid），签发时用最新的，验证时根据kid找对应秘钥，这样平滑过渡，用户完全无感知，是不是很妙？
最后唠叨几句
好了,关于JWT秘钥如何做，我差不多把压箱底的经验都掏出来了。
- 别硬编码,别用弱秘钥；
- 生产环境优先RS256；
- 秘钥要够长够随机；
- 记得定期轮换；
- 私钥千万藏好,公钥可以公开。
其实啊,JWT秘钥这事儿，说难不难，说简单也不简单，关键是要有安全意识，别为了图省事埋雷，你要是也在纠结JWT秘钥如何做，希望我这篇啰里啰嗦的文章能帮到你，有啥问题，欢迎留言唠嗑，咱们一起避坑！