我有一个客户端应用程序（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发布的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
答案 0 :(得分：0)
目前，我网站上的用户可以通过Auth0登录。身份验证数据存储在cookie中（如[1]中所述）。我的问题是：应始终使用有效的JWT
调用后端
假设我明白了，您可以将App A 授权视为从用户单独访问App B（后端api） 级身份验证（又名登录）。
基本上，将事物切割成两个不同的范围。
后者（后端应用程序）只是确保它只处理来自授权客户端应用程序（App A或任何其他可以创建App B所需的有效JWT的请求）的请求。
App A处理用户身份验证，并通过履行某些授权方案决定“何时/如何”调用您的App B，在这种情况下发送JWT及其请求。
Hth
答案 1 :(得分：0)
总结一下，我认为你的不确定性是如何处理＆＃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令牌在访客帐户之上具有特权访问权限，则可能包含其他范围。