客户端应用程序应该如何处理通过 OpenID Connect 获得的 JWT？

Question

我有一个场景，OIDC 似乎很适合：用户需要从服务器获取一些私人数据的移动应用程序。我已经阅读了 OIDC 教程such as this one，我想我理解了它们，但在全球范围内仍然存在一个至关重要的最终“漏洞”。

无论如何，如果我正确理解了 OIDC 的代码流，这是对交互的简要总结：

1. 移动应用程序将联系 OIP 授权端点，在 scope 中表明我们对用户的电子邮件感兴趣。它将以redirect_uri 的形式提供指向在移动应用本身中运行的简单网络服务器的指针。
2. OIP 将通过redirect_uri 联系移动应用程序，并向其提供授权码。
3. 移动应用现在将联系 OIP 令牌端点并向其提供在第 2 步中获得的授权代码。它还将向 OIP 提供必须发送回复的redirect_uri。
4. OIP 将通过redirect_uri 联系应用程序，并向其提供已签名的 JWT 以及我们请求的声明（电子邮件）。

教程到此结束。我认为现在暗示移动应用程序会将步骤 4 中获得的 JWT 发送到我的服务器。但是，服务器应该如何知道 JWT 是有效的？当然，它是由 OIP 签名的，但是服务器是否应该有一个硬编码的 OIP 公钥列表来验证 JWT？我发现的 OIDC 教程中似乎缺少这些最后的关键步骤...

Answer 1

OpenID Authorization Code flow]在第4点略有不同。一旦获得授权令牌，客户端向令牌端点请求令牌ID，返回包含ID令牌的响应，无需重定向（请求必须包含redirect_uri参数，服务器将确保与原始参数相同）

这是完整的OpenID Authorization code flow

1. 客户端准备一个包含所需的身份验证请求 请求参数。
2. 客户端向授权发送请求 服务器。
3. 授权服务器对最终用户进行身份验证。
4. 授权服务器获得最终用户同意/授权。
5. 授权服务器使用授权码将最终用户发送回客户端。
6. 客户端使用令牌端点的授权码请求响应。
7. 客户端收到响应正文中包含 ID 令牌和访问令牌的响应。
8. 客户端验证 ID 令牌并检索最终用户的主题标识符。

最后客户端必须根据3.1.3.4 ID Token Validation验证令牌。要点总结如下：

• iss 包含颁发者标识符和aud 您的client_id

• iat 和 exp 之间的当前时间

• 使用颁发者提供的密钥验证令牌的签名。在此流程中，TLS 服务器验证可用于验证颁发者，而不是检查令牌签名。在 HMAC 的情况下，client_secretof client_id 用作验证密钥

• 请求验证nonce、azp 或azr