.netcore之jwt加密token理解和原理

一，我们再使用jwt的时候，生成token到底是什么意思呢？如下生成解密后副本

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJ0ZXN0IjoidGVzdCIsInVpZCI6IjEiLCJuYmYiOjE2MDA2MTU1NjUsImV4cCI6MTYwMDYxNjQ2NSwiaWF0IjoxNjAwNjE1NTY1LCJpc3MiOiJ0ZXN0IiwiYXVkIjoiVGVzdEF1ZGllbmNlIn0.
vVrBFj8AK9i_jytc5wEQbqr0ei7JBYDGu3zKuEZvzcI

二，根据逗号，我们可以分割成三段,我们分别解释下生成原理吧，打开https://jwt.io/#debugger-io，官网，把我们的原文解密下，可得如下信息

 

 

三，这个时候我们小伙伴是不是很疑惑，这样大家都可以解密了，信息不是不安全了么，慢慢解释下，这里其实解密出来的对于我们前两段信息，这些一般我们都是存一些不敏感的信息，如果有需求的小伙伴可以自己MD5加密一下，这里第一二段加密实际上是base64，所以大家都可以解密，那问题来了，我们是怎么校验是否授权的呢？我们看第三段

vVrBFj8AK9i_jytc5wEQbqr0ei7JBYDGu3zKuEZvzcI

在官网解密出来的是这样的，这个是其实是根据你自己再生成token的时候才能解密，这样我们所以大家是看不到解密后的，那我们是不觉得这个很像对称加密，是的，我们就是用HS256加密的，如果你没有解密密钥，你是解密不了的，这样我们是不是知道授权的逻辑了呢，只要你能解密出第三密文，就证明你token是有效的还有验证时间之类的等等

四，这个时候我们又有疑问了，那第二段我们不是可以篡改，然后合并成token发过去么？那我们来解释下第三段的校验逻辑是，将第三段解密出来，然后和第一二端匹配，如果匹配是一模一样的表明没有被篡改 ，那我们有不理解了，第一二段那么长，第三段怎么那么段呢？其实，第三段解密出来的是第一二段MD5后的结果，如果能匹配上，就证明是没有篡改