oauth-2.0 - 用于 OAuth2 和移动应用程序的 PKCE 与 DCR

Question

我正在开发自己的 OAuth2 + OpenID Connect 实现。我对如何处理本机（特别是移动）客户端的 OAuth 流有点困惑。到目前为止，我看到我需要使用身份验证代码流。但是，根据我的研究，有些细节似乎相互矛盾（至少根据我目前的理解）。

首先，标准实践似乎表明移动应用程序本质上不是私有的，因此不应使用使用反向渠道的标准流程。作为一种解决方法，可以使用 PKCE 扩展（并利用内置设备浏览器而不是 Web 视图，因此令牌和敏感信息不太可能泄露）。

但是，根据协议的动态客户端注册规范，还提到移动应用程序应该使用这种客户端注册方法来获取有效的客户端 ID 和客户端密码......但是，我们为什么要这样做，而在前面的部分中它是确定移动应用程序确实是公共客户端，并且不能信任诸如客户端机密之类的机密信息（我们通过使用此 DCR 机制获得...

那么，我不明白什么？这两件事似乎相互矛盾。有人声称移动应用程序是公开的，不应该被信任秘密。然而，在推荐的 DCR 机制中，我们为他们分配了我们刚刚建立的无法信任的秘密。

谢谢。

标签： oauth-2.0oauth

Answer 1

有点晚了，但希望它有所帮助。所以 OAuth2.0 协议的一部分是两个组件，client_id 和 client secret。客户端和服务器必须在协议之外的这两个值上达成一致，即在协议开始之前。通常，过程如下。客户端使用越界通信通道与授权服务器通信以获取这些值并在服务器上注册。客户端注册有两种方式，静态和动态。静态意味着client_id 和secret 确实发生了变化，即客户端在向服务器注册时获取它们一次。动态客户端注册是指每次客户端想要使用协议时，注册一个client_id的过程，即每次都会为他生成一个client secret（也可以通过outbound通信）。

现在，为什么要使用动态注册？

动态客户端注册更适合跨复制的授权服务器管理客户端。最初的 OAuth 用例围绕单一位置 API，例如来自提供 Web 服务的公司的 API。这些 API 需要专门的客户端与它们对话，而这些客户端只需要与一个 API 提供者对话。在这些情况下，期望客户端开发人员努力将他们的客户端注册到 API 似乎并不是不合理的，因为只有一个提供者。

动态客户端注册是否提供任何安全优势？

不，如果与 JavaScript 或本机移动客户端一起使用，两者都容易受到攻击（可以检查 JavaScript 客户端，并且可以反编译移动应用程序）。因此，它们都需要 PKCE 作为额外的安全层。