问题描述
我想知道在OpenID Connect 身份验证代码流中，是否仍然需要验证 access_token 和 id_token 是通过我的Web服务器而不是通过浏览器获得的（即使用后通道而不是前通道）？
“身份验证代码流”是指浏览器仅从授权服务器接收“授权代码”的流（即，没有access_token，没有id_token），并将身份验证代码发送到我的Web服务器。因此，我的Web服务器可以直接与授权服务器对话，提供身份验证代码，并将其交换为access_token和id_token。看来我可以简单地解码access_token和id_token以获得我想要的信息（主要是用户ID等）
我对验证access_token的需求的理解是，由于access_token未加密，并且如果它是通过不安全的渠道传输的，，我的网络服务器就有机会获得伪造的令牌。验证令牌基本上是为了验证令牌是否已被修改。
但是，如果access_token没有在任何不安全的信道上传输怎么办？在auth代码流中，Web服务器直接从auth服务器检索access_token，并且该令牌永远不会发送到浏览器。我还需要验证令牌吗？如果我跳过此类流程中的验证，会有哪些潜在风险？
解决方法
您应该始终验证令牌，并对令牌应用众所周知的验证模式。因为否则您将为各种漏洞打开体系结构。例如，如果黑客拦截了您与令牌服务的“私人”通信，那么您将遇到中间人问题。
大多数库也会为您自动进行验证，因此验证不是问题。
在开发身份系统时，您应该遵循最佳实践和当前的各种最佳实践，因为这就是系统用户对您的期望。
作为客户端，您使用HTTPS从IdentityServer获取公共密钥，因此您知道从正确的服务器获取了什么。要添加其他安全层，您还可以使用客户端HTTPS证书，以便IdentityServer仅向使用证书进行身份验证的客户端颁发令牌。
这样，中间人几乎是不可能的。但是，在后端的数据中心中，有时内部不会在各处使用HTTPS。 TLS通常在代理中终止，您可以阅读有关here
的更多信息当您收到一个ID令牌时，通常会从中创建用户会话。是的，由于令牌是通过更安全的反向通道发送的，因此您可能会非常安全。但是今天仍然有很多攻击发生在内部，只是为了根据所有最佳实践做好工作，您应该对它们进行验证，包括签名和令牌中的声明（过期，发行者，受众...）。 / p>
对于访问令牌，重要的是接收它的API必须根据所有最佳实践对其进行验证，因为任何人都可以向其发送带有令牌的请求。
此外，它很有趣：-）
ps，这个video是一个很好的起点