oauth-2.0 - OpenID Connect 和服务器端授权代码流程

Question

我有几个问题。

授权代码流程和随机数

使用授权码流程时，是否需要在客户端验证随机数？在一般的 OAuth Provider 实现中，从授权代码获取访问 token 的过程仅进行一次。由此看来，Authorization Code Flow已经支持不使用nonce的重放攻击了？

授权代码流程和 ID token

在 Web 应用程序中使用授权代码流有哪些好处？ID Token是一种身份验证机制，而不是授权机制，我理解它用于验证哪个OpenID Provider正在为哪个中继方验证哪个用户。

但是在授权代码流程中，

• OAuth 2.0 需要使用 HTTPS。由此看来，如果正确实现了SSL证书验证，那么这将是一个有效的OpenID Provider的证明。
• 在一般的 OAuth Provider 实现中，当从授权代码获取访问 token 时，将在下面验证授权代码、客户端 ID 和 key 的组合。由此，将证明正在从正确的 OAuth 客户端执行访问 token 获取过程。
• 通过指定state参数创建授权请求，并在获取访问 token 时对其进行验证，将证明正在从正确的用户处获取访问 token 。

Answer 1

我不是 OpenID Connect 的权威，但这是我的两分钱......

Authorization Code Flow and nonce

Do I need to verify the nonce on the client side when using Authorization Code Flow?

规范规定，如果您在授权请求中发送随机数，则必须验证它(请参阅 http://openid.net/specs/openid-connect-core-1_0.html#IDToken 中的“随机数”)。但是，授权代码流程不需要发送随机数，因此您可以完全忽略它。在授权代码流的情况下，我认为你是对的，代码减轻了重放攻击——使得随机数变得不必要。然而，由于可以使用需要随机数的隐式/混合流程，因此 id_token 验证逻辑也可能是相同的，因为“如果在身份验证请求中发送了随机数值，则必须存在随机数声明及其检查值”

Authorization Code Flow and ID Token

What are the benefits of using Authorization Code Flow in web applications?

我认为授权代码流的好处是您可以将 token 保留在浏览器之外，并且可以仅将 token 保留在服务器端。

这是a helpful link about choosing the right flow for the right scenario