楼市政策最新消息,免费seo优化,网站的主色调,怎样用阿里云建设网站一.前言众所周知#xff0c;IdentityServer4 默认支持两种类型的 Token#xff0c;一种是 Reference Token#xff0c;一种是 JWT Token 。前者的特点是 Token 的有效与否是由 Token 颁发服务集中化控制的#xff0c;颁发的时候会持久化 Token#xff0c;然后每次验证都需… 一.前言众所周知IdentityServer4 默认支持两种类型的 Token一种是 Reference Token一种是 JWT Token 。前者的特点是 Token 的有效与否是由 Token 颁发服务集中化控制的颁发的时候会持久化 Token然后每次验证都需要将 Token 传递到颁发服务进行验证是一种中心化的比较传统的验证方式。JWT Token 的特点与前者相反每个资源服务不需要每次都要都去颁发服务进行验证 Token 的有效性验证该 Token 由三部分组成其中最后一部分包含了一个签名是在颁发的时候采用非对称加密算法最新的JWT Token进行数据签名的保证了 Token 的不可篡改性保证了安全与颁发服务的交互仅仅是获取公钥用于验证签名且该公钥获取以后可以自己缓存持续使用不用再去交互获得除非Token包含的 keyid 对应的 公钥没被缓存新的就会再次向颁发服务获取。我画了一张流程图大家可以去查看https://www.cnblogs.com/stulzq/p/9226059.html这里说一下我在文章说所说的名词颁发服务即生成Token的服务。资源服务提供给用户访问的API资源二.JWT Token 的安全问题前言中有过叙述JWT 类型的 Token 在验证的时候无需依靠颁发服务来验证 Token 的有效性是一种去中心化的验证方式这就意味着颁发服务无法集中控制 Token。假如 Token 暴露以后在 Token 有效期内将会一直被人恶意使用这时候该怎么办呢这里主要从两个方面来讲一个是尽量避免被恶意获取Token一个是被恶意获取了怎么控制失效。请听下面分解。1.使用 HTTPS此种方式是避免被人获取恶意获取Token。HTTPS 在传输数据时数据内容是加密的可以有效避免中间人攻击所以在使用 JWT Token 的程序建议都采用HTTPS。2.添加自定义Token失效机制此种方式是被恶意获取了怎么控制失效。因为 IdentityServer4 对 JWT Token默认是没有控制失效的机制的所以如果我们想添加这种机制只有我们自定义下一节做详细介绍。三.自定义Token失效机制1.简单黑名单模式顾名思义就是添加一个 Token 黑名单这个黑名单建议存在诸如 Redis 等分布式缓存数据库等介质可以让所有资源服务共同访问。不推荐添加在资源服务本地缓存如果这样做那么每次添加黑名单还需要同步到每个资源服务。每个资源服务在每次验证Token的时候需要查询一下黑名单如果在黑名单里面即 Token 无效。2.进阶黑名单模式前面小节的 【简单黑名单模式】 有一个非常大的弊端就是每个 Token 验证时都需要去验证是否在黑名单正常情况下我们正常的Token 是占绝大多数的如果用此种机制那么对资源是一种很大的浪费。那么我们需要设立一种机制来让我们认为 可疑 的Token进行黑名单验证那么如何来判断Token是否可疑呢我这里想了一种方式。如何判断 Token 是否可疑我们在生成Token的时候可以添加自定义 Claim 身份信息单元那么我们可以参考网站登录的安全机制那么我们可以添加一个用户ip的Claim这样我们生成的Token都会携带用户生成Token时的IP我们每次验证Token是否有效时就可以根据客户端来源IP与Token携带的IP进行匹配如果匹配不上那么该Token我们就可以认为是可疑的从而进行黑名单的验证。该方式相对于前面的 【简单黑名单模式】模式算是一个比较好的进阶了。在这里我们还需要考虑到IP作为用户的私密信息我们将IP放入Token时需要对IP进行加密。因为 JWT Token 前两部分仅仅是 base64 Encode 而已。Claim 详解请参考 http://www.cnblogs.com/stulzq/p/8726002.html3.强化黑名单模式无论是【简单黑名单模式】还是【进阶黑名单模式】我们在对比黑名单时是对token进行完全比对这样的方式在某些场景就存在局限性比我想让该用户在某某时间以前颁发的Token都算作黑名单。所以我们在判断黑名单时可以根据用户id以及token颁发时间来判断。如果让规则自动失效我们可以用前面设定的 token颁发时间加上我们颁发服务设置的token有效时间就等于规则失效时间。4.将Token添加进黑名单的方式我们前面设立了黑名单模式那么我们的Token何时加入黑名单呢难道让用户说我的 Token 被盗了你把我的 Token加入黑名单吧这肯定不现实。我们可以在退出登录时就自动往黑名单添加一条规则采用【强化黑名单模式】添加用户id以及当前时间作为token颁发时间来验证。比如用户id1000此用户在 2018-09-20 12:11 退出我们就可以添加一条规则 userid1000,tokenissuetime2018-09-20 12:11 ,该规则表示只要用户id为1000的并且token颁发时间小于2018-09-20 12:11的token都被算作黑名单token。这时有人可能会说这个token如果还是这个用户再次拿来使用那还是有效的你这个怎么没让他失效呢我们设立黑名单模式就是为了避免用户的还在有效期的Token被他人恶意使用。对于用户自己来说这个问题就无关紧要了。5.全部 Token 失效的机制。全部Token失效的方式目前我想了两种1.更换颁发服务的密钥对并且重启所有资源服务资源服务获取的公钥默认存在内存重启可以丢失。这样原本的Token在验证时将会找不到对应的公钥导致验签失败从而Token无效。2.类似于前面【强化黑名单模式】的验证黑名单的方式我们可以在验证Token的流程中加两个配置一个是控制这种配置是否开启的开关一个是某个时间规则就是如果在这个时间以前颁发Token全部算作无效Token。这种就需要资源服务支持热加载配置从而避免重启资源服务。我个人推荐第二种方式。四.其他解决方案这里的内容是根据评论整理的我个人的想法不可能面面俱到所以整理了一下评论里比较不错的方案SavorboardJWT 的最佳实践是遵循默认的过期策略(15分钟过期, 他能够有效的保证Token的有效性。 刷新Token是为了保证身份验证的服务端与授予令牌的客户端在访问权限方面保持一致比如Claim里可能包含最新的访问权限这是一个必要且必须的过程。所以频繁的15分钟刷新令牌是有必要的这并不足以对服务器的性能产生很大的影响。五.写在最后文中所诉是总结了我长久以来的想法token加入ip还有根据id和颁发时间验证黑名单都是我今天无意间想到的。如果你阅读了本文有什么不明白或者你认为有改进的地方或者更好的地方欢迎在评论与我交流。本文的问题有很多人问过我也讨论了不少我相信很多人在使用ids4是可能会有这样的问题所以在此发表了我的一个观点希望能给你参考后续的文章我会根据这个想法来实现。原文地址:https://www.cnblogs.com/stulzq/p/9678501.html.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com
