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