OpenID Connect id_token 和 access_token 如果是web server获取的，需要验证吗？

Posted 2023-03-28

【中文标题】OpenID Connect id_token 和 access_token 如果是web server获取的，需要验证吗？

【英文标题】：Do OpenID Connect id_token and access_token need to be validated if they are obtained by web server?

【发布时间】：2020-12-16 16:34:35

【问题描述】：

我想知道在 OpenID Connect Auth Code Flow 中，是否仍然需要验证 access_token 和 id_token是通过我的网络服务器而不是浏览器获取的（即使用反向通道而不是前端通道）？

“身份验证代码流”是指浏览器仅从授权服务器接收“授权代码”（即没有 access_token，没有 id_token）并将身份验证代码发送到我的 Web 服务器的流程。因此，我的 Web 服务器可以直接与授权服务器对话，提供身份验证代码，并将其交换为 access_token 和 id_token。看起来我可以简单地解码 access_token 和 id_token 以获得我想要的信息（主要是用户 ID 等）

我对需要验证 access_token 的理解是，因为 access_token 没有加密，并且如果通过不安全的通道传输，我的网络服务器有可能获得伪造的令牌.验证token基本上就是验证token没有被修改过。

但是如果 access_token 没有在任何不安全的通道上传输怎么办？在auth代码流中，web server直接从auth server获取access_token，这个token永远不会发送给浏览器。我还需要验证令牌吗？如果我在此类流程中跳过验证，会有哪些潜在风险？

【参考方案1】：

您应该始终验证令牌并应用众所周知的令牌验证模式。因为否则你会为各种漏洞打开你的架构。例如，如果黑客正在拦截您与令牌服务的“私人”通信，您就会遇到中间人问题。

而且大多数库会自动为您进行验证，因此验证不是问题。

当您开发身份系统时，您应该遵循最佳实践和各种当前最佳实践，因为这是系统用户对您的期望。

作为客户端，您使用 HTTPS 从 IdentityServer 获取公钥，因此您知道您从正确的服务器获得了什么。要添加额外的安全层，您还可以使用客户端 HTTPS 证书，以便 IdentityServer 仅向使用证书进行身份验证的客户端颁发令牌。

这样一来，中间人几乎是不可能的。但是，在后端的数据中心中，您有时不会在内部各处使用 HTTPS。通常 TLS 在代理中终止，您可以阅读更多关于 here

当您收到一个 ID 令牌时，您通常会从中创建用户会话。是的，由于令牌是通过更安全的反向通道发送的，因此您可以非常安全。但是今天仍然有许多攻击发生在内部，为了根据所有最佳实践做好工作，您应该验证它们，包括签名和令牌内部的声明（过期、发行者、受众......）。

对于访问令牌，接收它的 API 务必根据所有最佳实践对其进行验证，因为任何人都可以向它发送带有令牌的请求。

另外，学习很有趣:-)

ps，这个video 是一个很好的起点

【讨论】：

让我特别困惑的是，如果存在 SSL 条带/中间人攻击，我如何才能自信地验证我的令牌？为了验证令牌，我需要获取服务器的公钥——必须通过另一个获取请求来获取。如果中间有人，他也可以劫持这个通讯，然后把他用来伪造令牌的假钥匙给我？

谢谢。顺便说一句，无论如何，您的回答都非常有价值，我会接受。我无法理解的是 - 如果使用 HTTPS 从身份验证服务器获取公钥足以让公钥被认为是真实的，为什么同样的方式对令牌来说不够好？ access_token 和 id_token 都是使用 HTTPS 直接从身份验证服务器检索的。如果我可以信任公钥，我也应该信任这些令牌？

更新了我的答案，这如何使它可以接受，ps，大多数库都为你验证，所以我想知道你为什么不喜欢验证它们并确保安全？

我会，如你所说，验证它们以遵循惯例，但我确实想知道幕后发生的事情，而不是盲目地遵循惯例。确实有一些库声称可以为我处理所有复杂性，但我对这些库的健壮性/普遍适用性持怀疑态度，即它们是否都以相同的方式执行相同的验证集？如果是这样，它们必须可以互换吗？那我应该用哪一个呢？

这里有经过认证的库openid.net/developers/libraries，根据您使用的平台，请选择积极维护并具有开源代码的库。我确实同意您应该研究这些软件包并学习并了解它们是如何工作的，因为库确实存在错误。见auth0.com/blog/…和insomniasec.com/blog/auth0-jwt-validation-bypass