将 Google OIDC 与代码流和 PKCE 结合使用

经过反复试验，在我看来，Google OIDC 在不提供客户端密钥的情况下不支持代码流：https://developers.google.com/identity/protocols/oauth2/native-app#exchange-authorization-code https://developers.google.com/identity/protocols/oauth2/native-app#exchange-authorization-code

根据 SPA 的最新最佳实践（https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-13 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-13），代码流+PKCE是推荐的处理认证方式。有谁知道让 Google 的代码流接受 code_challenge 而不是 client_secret 所需的任何技巧？也许是一个虚假的秘密？

截至 2020 年 8 月，引用的最佳实践文件仍处于草稿阶段并正在积极更新 - 此处的头部修订版：https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/。 Google 的 OAuth2 实现尚未将 PKCE 的“正在进行的工作”建议应用于 Web 应用程序。 SPA 仍然被指示使用 Google 在线文档中的隐式流程：https://developers.google.com/identity/protocols/oauth2/javascript-implicit-flow https://developers.google.com/identity/protocols/oauth2/javascript-implicit-flow).

PKCE 标准（https://www.rfc-editor.org/rfc/rfc7636 https://www.rfc-editor.org/rfc/rfc7636）详细说明，它是为了缓解移动平台上发现的授权代码拦截攻击而开发的，最初建议由本机客户端实施。 Google 的“移动和桌面应用程序”文档确实指导开发人员使用 PKCE 授权代码流程。使用 Google Android、iOS 或 Windows 的客户端通过 PKCE 存储凭证类型可能会忽略client_secret（请参阅刷新令牌参数表上的注释 - 并由 Cristiano 确认）。

现在人们认识到 PKCE 消除了对any公共客户端来存储客户端机密，因此可用于弃用隐式流，该流始终存在在重定向 URI 中包含返回的访问和身份令牌的缺陷。https://developer.okta.com/blog/2019/05/01/is-the-oauth-implicit-flow-dead https://developer.okta.com/blog/2019/05/01/is-the-oauth-implicit-flow-dead.

IETF 文件草案第 2.1.1 节指出，这种认识很可能成为一项发布的标准。

希望 Google 能够更新其实施，以取消对client_secret当最佳实践被接受时，用于 PKCE 令牌请求。与此同时，我们似乎别无选择，只能继续使用隐式流程编写 SPA。