关于以下内容，我有一些事情需要澄清。“ OAuth 2.0 for Native Apps”规范说，
但是，由于隐式流不能被 PKCE [RFC7636]（第 8.1 节要求）保护，因此不建议将隐式流与本机应用程序一起使用。
为什么我们不应该使用隐式授权类型背后的这个推理让我感到困惑。
据我了解，授权代码授予需要 PKCE，因为它需要 2 个单独的调用来获取访问令牌，我们需要确保这两个请求都是由同一个应用程序完成的。如果我错了，请纠正我。
现在，由于隐式授权类型不需要这样的 2 次调用来获取令牌，我认为我们真的不需要 PKCE。如果我错了，请再次纠正我。
这意味着“隐式流不需要受 PKCE 保护”。那么为什么“隐式流无法被PKCE保护”成为上述避免将其用于本机应用程序的原因呢？
据我了解，授权代码授予需要 PKCE，因为它需要 2 个单独的调用来获取访问令牌，我们需要确保这两个请求都是由同一个应用程序完成的。
句子的第一部分不正确，第二部分（“我们需要确保......”）是。由于有 2 个请求，因此不需要 PKCE - 这两个请求使 PKCE 有可能实现。问题在于谁能在代码/令牌到达请求它的应用程序之前窃取它。隐式流与身份验证代码流具有相同的安全问题 - 在RFC的第 8.1 节中进行了描述。如果没有 PKCE，如果攻击者获得代码或访问令牌，他可以立即使用令牌或先将代码交换为令牌。使用 PKCE，代码在不知道code_verifier.
由于隐式流没有获得任何可以解决其安全问题的安全扩展，因此不推荐。
并且根据您选择的重定向 URI 选项，将重定向 URL 的片段部分（由隐式流用于传输令牌）传递给应用程序可能会出现问题。但我不确定这部分。