我们目前有一个使用 Identityserver4 2.0 构建的身份服务器。我们正在为我们的 API 添加一些政策指南。我一直在阅读许多教程，主要是这个 Policy-Based Authorization in ASP.NET Core
public void ConfigureServices(IServiceCollection services)
{
services.AddMvc();
services.AddAuthorization(options =>
{
options.AddPolicy("RequireElevatedRights", policy => policy.RequireRole("SuperAdministrator", "ChannelAdministrator"));
});
}
[Authorize(Policy = "RequireElevatedRights")]
public class ChannelAdministrationController: Controller
{
}
我认为我们对如何做到这一点有一些误解。据我了解，我们的 API 将检查当前用户授权并围绕该授权制定政策。基本上我们正在检查用户在 header 中发送的 token 是否正确？
我的问题是，如果用户在创建 token 后更改了权限。鉴于访问 token 的有效期为 1 小时，并且刷新 token 不会过期。这是否意味着拥有有效 token 的用户仍然可以访问一个小时的内容？
我们如何确保当前经过身份验证的用户实际上仍然有权执行声明中的操作？
最佳答案
这是 (jwt) token 的要点，您不必在每次请求时访问数据库。
身份 token (长期 token )和访问 token (短期，<= 60 分钟)不应包含授权相关数据。
身份 token 应仅包含很少更改且与用户身份相关联的声明(用户名、名字 + 姓氏、生日、电子邮件、email_verified 等)。
如果您希望它经常更改，请不要设置像“管理员”这样的角色。
授权(用户 A 是否允许创建这个那个，或者读取/查看资源)应该在一个单独的(每个服务)数据库中完成，你可以从那里获取它(如果需要的话还可以缓存)。
您的替代方案是，如果您确实已将此类“权限”放入 token 中或遇到需要立即生效的情况(受损帐户或解雇员工)，则您可以撤销 token 。
但请记住，撤销端点仅适用于刷新和引用(也称为不透明) token 。
您无法撤销开箱即用的 JWT token 。当然，您可以在 token 生成时将唯一(且随机)的 id 放入内存缓存(redis，本地缓存)中，并带有 token 的过期时间。
在每次请求时，您都会检查该 ID 是否仍在缓存中。如果它在那里并且 token 有效，则允许访问。否则拒绝。
当您进行一些敏感更改时，将一条消息发送到您的消息总线(rabbitmq、azure queues、redis)，触发一个处理程序从缓存中删除该 id，并在下一个请求中找不到该值缓存并将拒绝访问
关于security - 身份服务器 API 策略和角色，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49025755/