首页 > 解决方案 > 本机应用程序的隐式授权

问题描述

关于以下内容,我有一些事情需要澄清。“ OAuth 2.0 for Native Apps”规范说,

但是,由于隐式流不能被 PKCE [RFC7636](第 8.1 节要求)保护,因此不建议将隐式流与本机应用程序一起使用。

为什么我们不应该使用隐式授权类型背后的这个推理让我感到困惑。

据我了解,授权代码授予需要 PKCE,因为它需要 2 个单独的调用来获取访问令牌,我们需要确保这两个请求都是由同一个应用程序完成的。如果我错了,请纠正我。

现在,由于隐式授权类型不需要这样的 2 次调用来获取令牌,我认为我们真的不需要 PKCE。如果我错了,请再次纠正我。

这意味着“隐式流不需要受 PKCE 保护”。那么为什么“隐式流无法被PKCE保护”成为上述避免将其用于本机应用程序的原因呢?

标签: oauthoauth-2.0nativepkce

解决方案


据我了解,授权代码授予需要 PKCE,因为它需要 2 个单独的调用来获取访问令牌,我们需要确保这两个请求都是由同一个应用程序完成的。

句子的第一部分不正确,第二部分(“我们需要确保......”)是。由于有 2 个请求,因此不需要 PKCE - 这两个请求使 PKCE 有可能实现。问题在于谁能在代码/令牌到达请求它的应用程序之前窃取它。隐式流与身份验证代码流具有相同的安全问题 - 在RFC的第 8.1 节中进行了描述。如果没有 PKCE,如果攻击者获得代码或访问令牌,他可以立即使用令牌或先将代码交换为令牌。使用 PKCE,代码在不知道code_verifier.

由于隐式流没有获得任何可以解决其安全问题的安全扩展,因此不推荐。

并且根据您选择的重定向 URI 选项,将重定向 URL 的片段部分(由隐式流用于传输令牌)传递给应用程序可能会出现问题。但我不确定这部分。


推荐阅读