在 OAuth2 中存储 code_challenge 和 code_challenge_method 的最佳方式（PKCE 流程）

Question

OAuth2（PKCE 流程）

客户端应用程序调用/authorize授权服务器端点代码挑战和代码挑战方法.两个都代码挑战和代码挑战方法在授权服务器的后续请求中需要与用户凭据一起生成授权代码。

我可以想到两种存储方式代码挑战和代码挑战方法在后续调用中使用：

1. 坚持代码挑战和代码挑战方法在重定向到登录页面或用户同意页面之前
2. 通过代码挑战和代码挑战方法到查询参数中的登录页面，这些参数将与凭据一起提交

   由于RFC 没有谈论太多，哪个选项更好，为什么，或者还有其他选项吗？请建议。

   此外，是否有任何关于授权服务器端点的最佳设计实践（除了/authorize和/token) 在 OAuth2（PKCE 流）中的实现？

Answer 1

根据Add Login Using the Authorization Code Flow with PKCE

执行 PKCE 时有 2 个代码：

1. 验证码，随机字符串
2. 代码挑战者，来自代码验证者的哈希字符串，以及他的哈希方法，code_challenge_method

   在 Oauth2 authorization_code 流程中，您需要 2 个令牌：

   1. 授权令牌，请求accessToken
   2. accessToken，访问资源

      要使用 PKCE 获取授权令牌，您必须在 URL 参数中传递代码挑战者和方法，之后您不再需要它。

      因此，我假设您的问题更多是关于代码验证器的存储位置，在使用授权令牌请求访问令牌时，您需要将代码验证器添加到请求正文中。

      我认为您可以简单地将代码验证程序存储在应用程序的调用堆栈中。由于您应该在每次执行另一个授权链时重新生成一个新对（一旦您公开了该对，它们就不再是未知的），因此无论何时您获得访问令牌和刷新令牌，代码验证器都应该是无用的。

      您可以在请求授权令牌时打开一个新的导航器选项卡，然后您的应用程序等待身份验证提供程序将访问代码重定向回您的应用程序。看看如何flutter_web_auth（可以通过下载dart包获取源码）