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

Question

我有一个客户端应用程序（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进行身份验证）。此外，这意味着已经为该用户存储了一个配置文件，其中附有他/她的移动电话号码。由于允许用户访问资源，因此跳过发送验证码，除非用户移动号码与资源移动号码不匹配。我们称之为硬认证，因为用户 WITH 是一个存储的用户帐户。

所以 - 访客可能有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

Answer 1

  

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

调用后端

假设我明白了，您可以将App A 授权视为从用户单独访问App B（后端api） 级身份验证（又名登录）。

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

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

1. 后者（后端应用程序）只是确保它只处理来自授权客户端应用程序（App A或任何其他可以创建App B所需的有效JWT的请求）的请求。

2. App A处理用户身份验证，并通过履行某些授权方案决定“何时/如何”调用您的App B，在这种情况下发送JWT及其请求。

Hth

Answer 2

总结一下，我认为你的不确定性是如何处理＆＃34;客人＆＃34; （即，App A - ASP.Net核心网站的用户关于调用API B的问题（请注意术语 - 在这里你是在谈论API，而不是应用程序 - 从App的角度来看）甲

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

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

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