使用 Auth0 授权来自我们的 SPA 和其他 back-end 服务的 API 请求
Using Auth0 to Authorize API requests from both our SPA and our other back-end services
我们有一个调用我们的 back-end 服务（C# 和 Python）的单页应用程序，使用 Auth0 SPA 流程授权这些请求。
我们的后端服务仅在处理来自 SPA 用户的请求时相互请求，因此目前我们只是转发来自 SPA 请求的授权 header，使用它来授权操作每个调用服务。
我现在想添加 back-end 处理作业，这些作业将在我们的服务之间发出请求，从而调用现有端点。这些请求将没有任何现有的身份验证 header 可以转发，因此需要构建自己的身份验证。
根据 Auth0 文档，here and here，我认为我应该使用客户端凭证授权来授权这些请求，并且我推断我们现有的端点因此需要接受以两种不同方式授权的请求：来自 SPA 或其他服务。
问题是来自 SPA 的 JWT 是使用一个密钥签名的，而来自服务的 JWT 是使用它们各自的密钥签名的。我是否需要配置我的端点，以便它们接受使用这些密钥构建的 JWT？
所以我的核心问题是：这种理解是正确的，还是我应该换一种方式来理解？
详情：
我们的端点需要处理的两种授权 JWT 令牌是：
1 个来自我们 SPA 的请求，包含：
sub: SPA-USER-ID
aud: SPA-CLIENT-ID
使用 HS256（出于历史原因）使用我们 SPA 的客户端密钥进行签名。
2 Service-to-service 个请求，包含：
sub: SERVICE-ID@clients
aud: API-ID
scope: ""
使用我们调用服务的客户端密钥使用 HS256 签名（现在为了简单起见）。
如果一个端点要解码和验证两个请求，首先它将失败，因为 'aud' 值不同。我认为我们现有 SPA 调用的 'aud' 值是一个错误 - 它应该是接收请求的 API 的 ID。那么两个请求中的 'aud' 值将相同。
下一个区别是它们每个都使用不同的密钥签名——要么是 SPA 的要么是调用服务的（如果我选择按照 Auth0 的建议使用 RS256 进行新的服务调用，也可能使用不同的算法） .)
我找不到明显的方法来修改 Python 和 C# 快速入门以接受使用不同密钥编码的令牌。我正在考虑自己编写代码，手动尝试一个，如果失败则尝试另一个。我有信心我可以为 Python 端点授权做这件事，这是我自己写的基于 Auth0 quickstart 使用 PyJWT，但不太熟悉我们的 C# 东西，它也基于 Auth0 quickstart 但似乎使用一些 built-in .NET JWT 验证中间件，我完全不确定我是否可以深入了解其内部以添加上述功能。
但如果我以正确的方式执行此操作，那么这肯定是一个常见要求吗？
抱歉，如果这个问题是 badly-formed，我对身份验证一无所知，我正在阅读 Auth0/Oath2 文档来解决这个问题。
（回答我自己的问题，第三人称）
Is this understanding correct, or should I be doing it a different way altogether?
问题中概述的整体流程是正确的。然而有一个普遍的误解：
当服务（或 SPA）从 Auth0（或任何颁发者）请求新的访问令牌时，它们提供的密钥通常不是 Auth0 用来签署返回令牌的密钥。相反，发行者使用观众的密钥（将使用此访问令牌调用的 API。）
OP 对此感到困惑的原因是因为他继承的代码，如问题中所述，在请求令牌时错误地传递了 SPA 本身的 'audience' 值。因此，使用 SPA 的秘密对生成的令牌进行签名。修复此问题后，使用 API ID 作为 'audience'，则为 SPA 生成的令牌和为服务到服务调用生成的令牌将全部：
包含 audience=API-ID，因此将包含除 'sub'（用户 ID）和 'scope'（当前未使用）以外的所有方面的等效有效载荷.)
使用观众的 API-SECRET 与 HS256 签名。
因此，端点不必检查使用两个不同密钥编码的两种不同类型的令牌。它可以使用自己的 'audience' 标识符和自己的密钥检查传入请求，这将成功解码和验证来自 SPA 和其他服务的请求。
我们有一个调用我们的 back-end 服务（C# 和 Python）的单页应用程序，使用 Auth0 SPA 流程授权这些请求。
我们的后端服务仅在处理来自 SPA 用户的请求时相互请求，因此目前我们只是转发来自 SPA 请求的授权 header，使用它来授权操作每个调用服务。
我现在想添加 back-end 处理作业，这些作业将在我们的服务之间发出请求，从而调用现有端点。这些请求将没有任何现有的身份验证 header 可以转发，因此需要构建自己的身份验证。
根据 Auth0 文档，here and here，我认为我应该使用客户端凭证授权来授权这些请求，并且我推断我们现有的端点因此需要接受以两种不同方式授权的请求：来自 SPA 或其他服务。
问题是来自 SPA 的 JWT 是使用一个密钥签名的，而来自服务的 JWT 是使用它们各自的密钥签名的。我是否需要配置我的端点，以便它们接受使用这些密钥构建的 JWT？
所以我的核心问题是：这种理解是正确的，还是我应该换一种方式来理解？
详情：
我们的端点需要处理的两种授权 JWT 令牌是：
1 个来自我们 SPA 的请求，包含：
sub: SPA-USER-ID
aud: SPA-CLIENT-ID
使用 HS256（出于历史原因）使用我们 SPA 的客户端密钥进行签名。
2 Service-to-service 个请求，包含：
sub: SERVICE-ID@clients
aud: API-ID
scope: ""
使用我们调用服务的客户端密钥使用 HS256 签名（现在为了简单起见）。
如果一个端点要解码和验证两个请求，首先它将失败，因为 'aud' 值不同。我认为我们现有 SPA 调用的 'aud' 值是一个错误 - 它应该是接收请求的 API 的 ID。那么两个请求中的 'aud' 值将相同。
下一个区别是它们每个都使用不同的密钥签名——要么是 SPA 的要么是调用服务的（如果我选择按照 Auth0 的建议使用 RS256 进行新的服务调用，也可能使用不同的算法） .)
我找不到明显的方法来修改 Python 和 C# 快速入门以接受使用不同密钥编码的令牌。我正在考虑自己编写代码，手动尝试一个，如果失败则尝试另一个。我有信心我可以为 Python 端点授权做这件事，这是我自己写的基于 Auth0 quickstart 使用 PyJWT，但不太熟悉我们的 C# 东西，它也基于 Auth0 quickstart 但似乎使用一些 built-in .NET JWT 验证中间件，我完全不确定我是否可以深入了解其内部以添加上述功能。
但如果我以正确的方式执行此操作，那么这肯定是一个常见要求吗？
抱歉，如果这个问题是 badly-formed，我对身份验证一无所知，我正在阅读 Auth0/Oath2 文档来解决这个问题。
（回答我自己的问题，第三人称）
Is this understanding correct, or should I be doing it a different way altogether?
问题中概述的整体流程是正确的。然而有一个普遍的误解：
当服务（或 SPA）从 Auth0（或任何颁发者）请求新的访问令牌时，它们提供的密钥通常不是 Auth0 用来签署返回令牌的密钥。相反，发行者使用观众的密钥（将使用此访问令牌调用的 API。）
OP 对此感到困惑的原因是因为他继承的代码，如问题中所述，在请求令牌时错误地传递了 SPA 本身的 'audience' 值。因此，使用 SPA 的秘密对生成的令牌进行签名。修复此问题后，使用 API ID 作为 'audience'，则为 SPA 生成的令牌和为服务到服务调用生成的令牌将全部：
包含 audience=API-ID，因此将包含除 'sub'（用户 ID）和 'scope'（当前未使用）以外的所有方面的等效有效载荷.)
使用观众的 API-SECRET 与 HS256 签名。
因此，端点不必检查使用两个不同密钥编码的两种不同类型的令牌。它可以使用自己的 'audience' 标识符和自己的密钥检查传入请求，这将成功解码和验证来自 SPA 和其他服务的请求。