IdentityServer4：数据库中不同表中的不同用户类型

Question

当前情况：我有一个包含3个WebAPI项目的应用程序（假设API A，B，C）。每个都有基于令牌的身份验证（基于OAuthAuthorizationServerProvider）。用户类型共有3种（假设类型1、2、3）。每种用户类型都存储在单独的数据库表中；

• 移动客户端（“类型1”用户）使用的“ API A”
• “ API B”部分由移动客户端（“类型1”用户）使用，部分由Web客户端（角度应用程序，“类型2”用户）使用
Web客户端（“类型3”用户）使用的
• “ API C”

也是

• “类型1”用户可以从“ API A”获取令牌并将其从“ API B”交换为另一个令牌，以便访问“ API B”资源（“ Type B”使用的“ API B”中的某些控制器1”用户，其他-“类型2”用户）
• “类型2”用户具有两步授权
  • 他们使用登录名和密码来获得对单个控制器具有“受限访问”权限的令牌，以便从中选择一些值
  • 使用先前的令牌和选择的值，他们将其交换为“完全访问权限”令牌

我打算从当前的授权方案迁移到IdentityServer4。所以，我有几个问题：

主要问题：

1. 如何通过具有单个IdentityServer4实例的单个端点（服务器/连接/令牌）对3个不同数据库表中的3个不同用户类型进行身份验证？

其他问题：

1. 如何为“类型2”用户实施两步授权？
2. 在我的情况下您能提供什么建议？

谢谢！

Answer 1

对于IdentityServer，只有一种类型的用户需要进行身份验证。因此，所有用户都应移至同一表（如何迁移是另一个问题）。如果将用户移动到一个表是一个问题，则IdentityServer可能不是实现安全性的正确工具。尽管可以通过实现自定义用户存储来维护单独的表。可以为每个用户启用两因素身份验证。您可以使用扩展授权来实现自定义授权。

安全性的全部目的是保护您的资源：api。在IdentityServer中，资源名称是该功能的逻辑名称，该功能可以拆分为多个范围，其中范围是特定功能。

Api1可以是具有多个范围（例如Api1.Read和Api1.Write）的资源，也可以只是Api1。但是Api1，Api2和Api3也可以成为Api资源的一部分，其中Api1，Api2和Api3位于事实范围。在您的情况下，Api1可能是资源，其中Api1是 scope 。

要使用户能够访问资源，您需要一个客户端应用程序，尽管您可以有许多可以访问同一资源的客户端。为了支持不同类型的客户端，可以选择多种授权类型。

---

IdentityServer允许您配置完整图片。

我们假设有一个客户端可以访问不同的Api，其中每个Api都是资源/作用域。

需要允许客户端代表用户访问Api的 ，因为没有用户，客户端无法访问资源。

因此，应允许客户端使用某些范围，而该范围需要由客户端请求。没有这个，客户端将无法访问资源。假设为Api1和Api2配置了客户端，但是客户端仅请求Api1。然后Api2和Api3无法访问。

这都是顶级授权的一部分。现在是时候让用户参与了。当客户端访问api时，api会知道哪个用户发出了请求（因为sub是访问令牌的一部分）。但这还不足以授予或拒绝访问。

因此，您需要一些授权用户。关于如何实现这一点，有很多选择。看看documentation。

考虑一个简单的实现，其中有三个策略。并且每个策略都确保只有匹配类型的用户才能访问。

那么实际的问题是，如何区分用户类型？

---

您可以在 UserClaims 表中添加声明。假设 ClaimType 为UserType，而 value 为1。在资源中添加一个策略，用于检查声明UserType和所需的值。

为了让IdentityServer将声明添加到访问令牌中，请确保ClaimType是范围的一部分（或在配置了多个范围并且需要ClaimType时为ApiResource）。

通过将ClaimType UserType添加到Api_范围，意味着在访问该范围时，必须包括该声明。 IdentityServer尝试通过仅过滤请求的声明来限制访问令牌中的声明数量。

当用户访问Api_时，声明应该是访问令牌的一部分（假设为每个用户设置了声明，否则用户根本没有访问权限）。您可以对其他api（作用域）重复此设置。

在这种情况下，我认为这是可以接受的解决方案。其他选项是较低级别的授权（基于资源）或外包的授权，例如PolicyServer。

请注意，由于SSO，用户也有可能被其他客户端验证。但是，由于仅将访问权限授予某些类型的用户（作为策略的一部分），因此您可以防止其他类型的用户访问不适合他们的资源。您可以通过禁用自动登录来防止此行为。