PKCE 是否替换授权代码 OAuth 流程中的状态？

信息安全 oauth oauth2
2021-08-21 15:00:31

PKCE解释：https ://www.oauth.com/oauth2-servers/pkce/

OAuth 流程示例：https : //developer.okta.com/docs/guides/implement-auth-code-pkce/use-flow/

我的问题更具体：如果实施 PKCE，是否有任何理由要求 state？

state通过让应用服务器验证它给客户端的状态与客户端给它的状态相同（在发出第一个 OAuth 请求之后）来阻止CSRF攻击

  1. stateApp Server为每个唯一的客户端随机生成并提供给客户端
  2. 客户端发送state到 Auth Server，Auth Server 返回状态和代码
  3. 客户端向 App Server 发送state和编码
  4. 应用服务器确保state在第 1 步 ==state在第 2 步

但是，如果您使用 PKCE 执行此操作：

  1. App Servercode_challenge为每个唯一的客户端生成随机数并将其提供给客户端（我们现在可以忽略可选的散列）
  2. 客户端提供code_challenge给 Auth Server，Auth Server 返回代码
  3. 客户端向应用服务器发送代码
  4. 应用服务器code_challenge在步骤 1 中将代码 & 发送到验证服务器，验证服务器code_challenge在步骤 1 ==code_challenge步骤 2 中进行验证

这似乎是完全相同的流程，除了您必须将其存储code_challenge在您的服务器上，而不是state存储在您的服务器或客户端的 cookie 中，并且最终检查由 Auth Server 而不是 App Server 完成。

1个回答

由 OAuth2 服务器在重定向的stateurl 中返回，因此客户端应用程序可以验证打开授权页面的请求确实是由自身触发的。

code_challengeOAuth2 服务器不会返回，但客户端应用程序必须在下一个请求中发送所有物code_verifier，以将授权码交换为令牌。然后，OAuth2 服务器可以确定它是第一个请求打开授权页面的客户端应用程序。

即使攻击者侦听了第一个请求和以下重定向，（s）他也不知道code_verifier，它永远不会通过网络发送。这使得不可能（错误地）使用重定向并冒充客户端来获取令牌。

所以是的，两者都是必需的，状态在 open-authorization-page-request 和重定向之间建立了链接，而 code_challenge 在 open-authorization-page-request 和 exchange-code-for-token-request 之间建立了链接。

其它你可能感兴趣的问题
上一篇是否可以通过文件名上传图像来获取 XSS？ 下一篇使用公共 API 的安全注意事项