Question

我对如何同时使用身份验证和授权的集中式IDP感到非常困惑。我的项目的架构是一个Web API和一个React客户端。我想将事物结构化到微服务中，只是为了尝试更现代的事物，但是与其他许多人一样，我在集中化身份方面遇到了主要问题。

我的目标很简单。用户登录，从他们有权访问的租户列表中选择一个租户，然后将他们重定向到具有角色和“ tid”或租户id声明的客户端，该声明只是所选公司的GUID。

Microsoft在我的方案中添加身份的规定方法是IdentityServer，因此我从此开始。直到我发现代币的内部运作，一切都顺利进行。尽管其他一些人在添加权限时遇到问题，但我的应用程序中的授权逻辑非常简单，角色就足够了。尽管最初通过过期自然刷新角色会很好，但是只要我的用户选择其他租户“登录”，它们就必须立即更新。但是，问题在于，当用户更改租户而不注销时，我无法刷新这些声明。本质上，我尝试将授权与身份验证混合在一起，然后碰壁。

似乎我有两个选择：

从单独的提供程序或身份服务器本身的端点上获取授权信息，例如/ user-info，但获取授权信息。最终增加了巨大的开销，但是服务器和客户端的实际样板很小。尽管我不知道他们的付费实施方式如何，这与PolicyS的OSS版本的PolicyServer相似。我的主要问题是客户端和资源（API）都需要此信息。如何避免每次互动产生N个请求（其中N是资源/客户端的数量）？
实施某种自定义状态，并保留需要刷新其JWT的用户存储。检查这些并返回一些自定义响应给调用者，然后调用者使用自定义js客户端代码刷新此响应上的令牌。这是一个巨大的理论，即使是合理的，它仍然会引入状态，并在需要大量自定义代码的同时使JWT的作用点失效。

因此，我对冗长的帖子表示歉意，但这确实让我感到讨厌。我不需要使用IdentityServer或JWT，但是我至少希望有一个React前端。对于最新的租期选择和角色，我有哪些选择？就在我愿意让步并实现返回新鲜数据的授权端点时，我意识到我会同时在API和客户端每个请求中调用它。即使使用缓存的数据，仅使用纯HTTP调用也要付出大量的开销。有一些替代解决方案可以在这里工作吗？老实说，我能否仅使用包含授权信息的Cookie进行验证，并且仅在必要时进行更新？

Answer 1

当您要按原样使用IdentityServer进行用户授权时，这会造成混乱。分开关注。

如多米尼克·拜尔（Dominick Baier）的commented：

是–我们建议使用IdentityServer进行最终用户身份验证，联盟和API访问控制。

PolicyServer是我们建议的用户授权。

选项1似乎是推荐的选项。因此，如果您决定采用选项1：

PolicyServer的OSS版本足以处理请求。但是不要使用json config file：

// this sets up the PolicyServer client library and policy provider
// - configuration is loaded from appsettings.json
services.AddPolicyServerClient(Configuration.GetSection("Policy"))
    .AddAuthorizationPermissionPolicies();

从端点获取信息。添加缓存以提高性能。

为了允许集中访问，您可以创建单独的策略服务器或使用用户授权端点扩展IdentityServer。使用extension grants访问用户授权端点，因为您可能想区分客户端和api。

json配置是本地的。新的端点将需要它自己的数据存储，可以在其中读取用户声明。为了允许集中的信息，请添加有关可以在何处使用权限的信息。我个人使用范围对权限进行建模，因为客户端和api都知道范围。

最后一步是添加管理界面或端点以维护用户授权。

Answer 2

任何人都想知道我是如何做到这一点的，这是一个很长的故事，但我最终只是根据其他人的说法和指导方针来分离权限。门户概念只是行不通，因为我无法弄清楚如何“软”注销用户，在操作后刷新他们的令牌而不会脱节或让他们再次输入他们的凭据。

我最终使用远程 gRPC 调用进行授权。您可以在 https://github.com/Perustaja/CoreMultiTenancy

使用IdentityServer4处理授权

2 个答案: