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

Question

我想知道在 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永远不会发送给浏览器。我还需要验证令牌吗？如果我在此类流程中跳过验证，会有哪些潜在风险？

Answer 1

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

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

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

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

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

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

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

另外，学习很有趣:-)

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