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

Posted 2023-03-08

【中文标题】使用 Auth0 授权来自我们的 SPA 和其他后端服务的 API 请求

【英文标题】：Using Auth0 to Authorize API requests from both our SPA and our other back-end services

【发布时间】：2017-10-14 11:47:56

【问题描述】：

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

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

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

根据 Auth0 文档 here 和 here，我认为我应该使用客户端凭据授予来授权这些请求，并且我推断我们现有的端点因此需要接受以两种不同方式授权的请求：来自 SPA 或其他服务。

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

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

详情：

我们的端点需要处理的两种授权 JWT 令牌是：

1 来自我们 SPA 的请求，包含：

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

使用我们 SPA 的客户端密码使用 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# 东西不太熟悉，它也基于 Auth0 快速入门，但似乎使用了一些内置的.NET JWT 验证中间件，我完全不确定我是否可以通过它的内部来添加上述功能。

但是，如果我这样做是正确的，那么这肯定是一个常见的要求吗？

抱歉，如果这个问题的格式不正确，我对身份验证一无所知，并且正在阅读 Auth0/Oath2 文档以解决问题。

【问题讨论】：

啊哈：回答我自己关于对新的服务到服务请求使用不同的签名算法的隐含子问题：这应该没问题，因为使用的算法是由 JWT 标头指定的，所以如果需要，每个请求都可以使用不同的算法进行解码。

【参考方案1】：

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

这种理解是否正确，还是我应该完全不同的方式？

问题中概述的整体流程是正确的。但是有一个普遍的误解：

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

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

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

使用观众的 API-SECRET 与 HS256 签署。

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