具有多个身份验证源的JWT令牌

Posted 2021-04-08

我有一个客户端应用程序（JS）由一个简单的ASP.Net核心网站提供（让我们称之为'网站A'）。 “网站A”的目的是简单地提供网站。这意味着，没有业务逻辑，它基本上也可以是php / Rails / Whatever站点（为准备OrchardCore发布的是ASP.Net Core）。客户端应用程序（JS）通过传递共享cookie进行身份验证来调用我的后端api（另一个ASP.Net Core站点 - 让我们称之为'API A'）（所以 - 'API A'可以处理由'Website A'创建的cookie ）。这意味着，所有业务逻辑都通过“API A”处理。换句话说：目前“网站A”处理身份验证（如[1]中所述），客户端应用程序（JS）只调用“API A”。 '网站A'本身不会对'API A'进行任何调用 - 它只是用于提供网站。我想将此行为转换为纯JWT身份验证。身份验证将通过我的客户端应用程序处理 - 因此'网站A'基本上不会再创建cookie。

目前，我网站上的用户可以通过Auth0登录。身份验证数据存储在cookie中（如[1]中所述）。我的问题是：应始终使用有效的JWT调用后端 - 但我不需要登录（因为这是可选的）。 api公开了一个资源，它有一个与之相关的手机号码。这导致两种身份验证选项：

• 来宾正在尝试访问此资源。验证码被发送到附加到资源的移动号码。提交有效的验证码后，允许访客访问该资源。从此刻起，身份验证上下文将在整个会话期间保留 - 除非用户尝试访问附加了不同移动电话号码的其他资源。让我们称之为软身份验证，因为从那时起来宾不是真正的访客而是经过验证的访问者（所以说：没有存储用户帐户的用户）。
• 用户已经过身份验证（已登录并因此通过Auth0进行身份验证）。此外，这意味着已经为该用户存储了一个配置文件，其中附有他/她的移动电话号码。由于允许用户访问资源，因此跳过发送验证码，除非用户移动号码与资源移动号码不匹配。我们称之为硬认证，因为它是具有存储用户帐户的用户。

所以 - 访客可能有一个由Auth0发布的JWT或者......好吧 - 或者是什么？我发行的JWT？我的API（'API A'）应验证Auth0令牌，如[2]中所述

使用JWT基于软认证或硬认证访问我的API（'API A'）的最佳方法是什么。

---

关于术语'网站A'和'API A'的说明

在稍后阶段，可能有多个网站（就品牌网站而言）都应使用相同的后端API。因此，可能会有一个'网站A'提供'品牌A'和'网站B'提供'品牌B'。在准备拆分为微服务的API A'后来可能是一堆API - 'API A'，'API B'，......

---

[1] https://auth0.com/docs/quickstart/webapp/aspnet-core/01-login

[2] https://auth0.com/docs/quickstart/backend/aspnet-core-webapi

答案

目前，我网站上的用户可以通过Auth0登录。身份验证数据存储在cookie中（如[1]中所述）。我的问题是：应始终使用有效的JWT调用后端

假设我理解，您可以将App A授权访问App B（后端api）与用户级别身份验证（即登录）分开。

• 用户身份验证不会更改。登录就像你拥有它一样完成。
• 然后，您可以定义App A如何单独向App B发出后端请求。

从本质上讲，将事物切割成两个不同的范围。

1. 后者（后端应用程序）只是确保它只处理来自授权客户端应用程序（App A或任何其他可以创建App B所需的有效JWT的请求）的请求。
2. 应用程序A处理用户身份验证，并通过履行某些授权方案决定“何时/如何”调用您的应用程序B，在这种情况下，发送带有请求的JWT。

心连心

另一答案

总而言之，我认为你的不确定性是如何处理“客人”（即App A - ASP.Net核心网站的用户关于调用API B的问题（请注意术语 - 在这里你要谈的是从App A的角度来看，一个API，而不是一个应用程序。

此外，您使用Auth0作为身份提供者（IDP）进行App A身份验证。它目前向经过身份验证的用户发出（JWT）ID令牌和访问令牌以调用API（如果您请求，还可选择刷新令牌）使用offline_access范围。但挑战在于您的“访客”用户（即未经身份验证的用户）没有JWT访问令牌。

以下内容可能适合您的需求。在Auth0仪表板（又名资源API）中设置API - https://auth0.com/docs/api-auth/grant/authorization-code

此外，由于您使用的是ASP .NET Core - 并且您的服务器端应用程序被视为“机密客户端” - 它可以存储客户机密钥。因此，创建非交互式客户端 - https://auth0.com/docs/clients/client-settings/non-interactive并将其注册到您的（新创建的？）资源API是合适的。现在，对于guest虚拟机，您可以继续使用非交互式客户端获取安全API B端点的JWT Access令牌，并在调用API时使用它。根据您的需要，您可以确保Guest JWT Access Token仅返回适用于Guest帐户的“范围”。如果经过身份验证的用户JWT令牌具有访客帐户之上和之上的特权访问权限，则可能包含其他范围。