2017-03-07 91 views
0

人们通常是否将权限存储在JWT中?我见过的例子可能有admin: truescopes: ['add_foo', 'delete_foo', 'read_foo']。这看起来很好,除此之外,如果有很多权限/范围,JWT可能会变得很大。看起来它会非常有用,因为只要JWT可以验证,您就不需要访问数据库或缓存来获取用户权限。权限上的JWT失效

但我的主要问题是如何在权限更改的情况下这些将被无效。

例如,系统管理员Joe撤消用户Bob的'add_foo'和'delete_foo'权限,但保留'read_foo'权限。在这种情况下,用户Bob不应让他的令牌完全失效并需要重新登录,他应该基本上被迫使用新的权限获得新的JWT并继续正常运行。

我见过的例子解释了在发生密码更改时发布新的JWT,但这里的区别在于系统管理员Joe对用户Bob进行了更新。因此,用户Bob在此工作流中没有机会立即获取新令牌。

大多数示例都建议维护被吊销令牌的黑名单,或者更改数据库记录ID以使令牌不再有效,或者拥有每个用户的机密并更改该凭证。

我看到所有这些都可以用于撤销令牌并测试其无效,但用户如何获得新令牌?他们目前的JWT现在是无效的?试图用它做任何事情都会失败。

我见过提到“刷新令牌”。这些广泛使用?他们是否安全在网上或主要用于刷新令牌难以获得的移动应用程序。似乎通过浏览器开发工具或类似软件窃取刷新令牌似乎是相当容易的,然后有人可以永久访问该帐户,直到发现未经授权的访问并撤销刷新令牌为止。

也许在这种情况下强制用户Bob重新认证并不是什么大不了的事?权限可能不会经常更改。

谢谢,迈克。

回答

0

您可以设置截止日期(对于Web应用程序,我们通常使用15分钟 - 30分钟,移动1周)。当您设置发行在索赔参数(“iat”)。然后每当你验证令牌时,你应该检查令牌的“年龄”。如果它超过5分钟,则从数据库加载数据并创建新的令牌,其值为当前“iat”值。

0

当权限更改时,您应该使此用户的已发出令牌无效。有不同的技术可以使用。请参阅Invalidating client side JWT session

但考虑撤销令牌并不是推荐的做法,因为您失去了JWT的一个主要优势:它不需要服务器存储。

Oauth2.0定义的的刷新令牌目的,是允许应用程序获得一个新的访问令牌,无需重新进行身份验证

刷新令牌用于获得访问令牌凭据。刷新令牌由授权服务器发布给客户端,用于在当前访问令牌变为无效或过期时获得新的访问令牌,

如果权限不频繁改变,验证用户,如果他们改变太多,考虑他们是否真的应该包含在令牌中