使用Auth0授权来自我们的SPA和其他后端服务的API请求

Question

我们有一个单页应用程序，该应用程序调用我们的后端服务（C＃和Python），并使用Auth0 SPA流授权这些请求。

我们的后端服务仅在处理SPA用户的请求的过程中相互发出请求，因此当前我们仅转发SPA请求中的Authorization标头，并使用它来授权对每个被调用服务的操作。

我现在想添加后端处理作业，这些作业将在我们的服务之间发出请求，并调用现有端点。这些请求将没有任何要转发的现有auth标头，因此需要构造它们自己的请求。

基于该Auth0文档，这里和这里，我相信我应该使用一个客户端凭证授予授权这些要求，我推断，我们现有的端点将因此需要接受授权两种不同的方式请求：从SPA或其他服务。

问题在于，SPA中的JWT使用一个密钥进行签名，而服务中的JWT使用其各自的密钥进行签名。我是否需要配置端点，以便它们接受使用任何这些秘密密钥构造的JWT，对吗？

因此，我的核心问题是：这种理解正确吗，还是我应该以完全不同的方式来做？

细节：

我们的端点需要处理的两种类型的Authorization JWT令牌是：

来自我们SPA的1个请求，其中包括：

sub: SPA-USER-ID
aud: SPA-CLIENT-ID

使用HS256的客户机密，使用HS256（出于历史原因）签名。

2个服务到服务的请求，其中包括：

sub: SERVICE-ID@clients
aud: API-ID
scope: ""

使用我们的呼叫服务的客户机密使用HS256（为了使事情简单）进行签名。

如果一个端点要解码并验证两个请求，则首先将失败，因为“ aud”值不同。我认为我们现有SPA调用的“ aud”值是一个错误-应该是接收请求的API的ID。然后，两个请求中的“ aud”值将相同。

下一个区别是它们每个都使用不同的秘密密钥签名-SPA或呼叫服务的签名（如果我选择按照Auth0建议使用RS256进行新的服务调用，则也可能使用不同的算法）。

我找不到明显的方法来修改Python和C＃快速入门以接受使用不同键编码的令牌。我正在考虑自己进行编码，以手动尝试其中一种，如果失败，则尝试另一种。我有信心可以为Python端点授权做这件事，我是根据PyJWT的Auth0快速入门编写的，但对我们的C＃东西不太熟悉，C＃的内容也基于Auth0快速入门，但似乎使用了一些内置功能.NET JWT验证中间件，我完全不确定是否可以添加上述功能。

但是，如果我以正确的方式进行操作，那么这肯定是常见的要求吗？

如果这个问题的格式不正确，我深表歉意，我对auth一无所知，并且正在阅读Auth0 / Oath2文档以在进行过程中弄清楚。

Answer 1

（以第三人称回答我自己的问题）

这种理解是否正确，或者我应该以完全不同的方式来做？

问题中概述的总体流程是正确的。然而，人们普遍存在一个误解：

当服务（或 SPA）向 Auth0（或任何颁发者）请求新的访问令牌时，它们提供的密钥通常不是 Auth0 用于签署返回令牌的密钥。相反，发行者使用受众的密钥（将使用此访问令牌调用的 API。）

OP 对此感到困惑的原因是因为他继承的代码（如问题中所述）在请求令牌时错误地传递了 SPA 本身的“受众”值。因此，生成的令牌是使用 SPA 的秘密进行签名的。修复此问题后，若要使用 API ID 作为“受众”，则为 SPA 生成的令牌以及为服务到服务调用生成的令牌将全部：

1. 包含 Audience=API-ID，因此将包含除“sub”（用户 ID）和“scope”（当前未使用）之外的所有方面的等效有效负载。

2. 使用受众的 API-SECRET 与 HS256 进行签名。

因此，端点不必检查使用两个不同密钥编码的两种不同类型的令牌。它可以使用自己的“受众”标识符和自己的密钥检查传入请求，这将成功解码和验证来自 SPA 和其他服务的请求。