JWT原理 对比 appid secretkey 鉴权

参考

看东西就先看官网

小结

大概思想就是

1、客户端用用户名密码请求server，server校验通过之后，返回JWT，里面包含着用户信息（base64编码的payload可破解，不应该包含敏感信息）
2、客户端从此在header上带着这个JWT请求server
3、server拿到JWT，解密成功则说明鉴权成功，否则鉴权失败

问题

流程是这么个流程，但感觉疑点重重

问题1、具体应用场景是啥，JWT里存什么呢

参考这个：比较正确的用法

我是单纯瞎想的，没有实证。拿钉钉做例子吧，有点类似于单点登录的感觉

假设用户登录了钉钉之后，其实可以以钉钉的身份登录别的应用如钉钉日历访问资源，其实没有必要再登录钉钉日历的系统了。具体应该怎么做呢？

我们可以想象有一个钉钉统一的passport模块，用户登录了钉钉之后，实际上就是在passport模块输入用户密码校验成功，然后passport模块返回一个JWT，payload里记录了用户可以访问的应用，如{“auth_apps”: [钉钉日历、钉钉文档]}，那么当用户带着这个JWT去访问钉钉日历的时候，实际上钉钉日历的后端系统可以解密出用户有权限的app，发现包含钉钉日历，于是允许访问。（当然先要校验签名：拿payload里的用户id去数据库中找到JWT对应的secretKey，然后用相同的方法做出签名，如果签名和JWT的第三个签名部分相等，说明这个JWT有效。）

这么做是否有问题呢？别人是否能够通过修改payload里的auth_apps来访问原来没有权限的app，如在auth_apps里加上钉钉顺风车? 答案应该是不行的，因为如果篡改了payload，签名就会发生改变，签名也就失效了。

问题2、这个跟appid+secretKey的鉴权有啥区别？

一般的openapi模块，会给不同的应用方分配appid+secretkey，同时开放加密算法，应用方将请求内容+appid等信息拼接字符串后，用secretKey签名（加密算法与JWT类似，如HMAC SHA256之类的），然后server端做鉴权的时候用相同的加密算法加密一遍得到token，与应用方传过来的token做比对，实现鉴权。

这里的appid有点像JWT里的payload。都是明文可获取的。但是JWT不要求客户端保存secretKey和加密算法，只需要保存JWT这个字符串就行了。加密的过程都在server端。

JWT会定时过期，过期后需要向server重新申请新的JWT。

小结2

可以对比 CAS 的方案，各种有啥优缺点？

后面有新的想法可以to be continued