从OpenID的角度和我读过的所有问题/文章来看，这似乎很不言自明——它是请求ID令牌的客户端应用程序。然而，当我试图将它映射为我们架构中的实际"应用程序"时，我并不完全确定。
给定：
- ID_Token的受众是Client_Application
- Access_Token的受众面向受保护资源API
- 我们有一个前端SPA，它有自己的后端web API(稍后可能会被其他客户端使用)
涉及的组件包括：
- 前端SPA(依赖方)
- 后台Web_API(受保护的资源)
- OpenID提供程序(OP)
如果我想在用户访问Front-end SPA时应用Auth Code流，Front-end SPA或Web_API会被视为Client_Application吗？在Auth-Code流中，ID_Token的Auth_Code的实际交换将通过后端Web_API到OP的后通道进行。然而，最初请求用户身份验证的实际上是前端SPA。ID_Token的受众应该是什么？是SPA还是Web_API的App_ID？
感谢您的澄清。
当前的最佳实践要求SPA使用PKCE的授权代码流(最佳实践rfc草案)。因此，在SPA中使用OAuth时，请考虑这一点。
关于您的疑问，以下是您的客户和受众
- 客户-您的SPA
- ID代币的受众-您的SPA
- 访问令牌的受众-后端web API
正当性：
正是您的SPA完成了OAuth流并获得了令牌。正如我所说，它必须遵循PKCE作为当前的建议(有足够的库来支持这一点)。所以从授权服务器的角度来看，客户端就是您的SPA。
关于ID代币，它将由您的SPA消费。验证SPA后，对最终用户进行身份验证。所以它的目标受众是SPA。
访问令牌旨在由您的SPA针对您的后端使用。一旦收到API请求，它必须检查访问令牌受众是否包含以自身为目标的标识符(例如：-如果是JWT，则声明包含后端标识符。或者如果是令牌内省，则声明中包含标识符)。通常，您的授权服务器允许您注册此类受众，并且您的授权请求可以具有预期受众参数(例如：Azure使用此方法)。但这些都是具体的实施细节。