针对 OAuth2 和移动应用程序的 PKCE 与 DCR
PKCE vs DCR for OAuth2 and Mobile Applications
我正在开发自己的 OAuth2 + OpenID Connect 实现。我对如何处理本机（特别是移动）客户端的 OAuth 流程感到有点困惑。到目前为止，我发现我需要使用身份验证代码流。然而，根据我的研究，有一些细节似乎相互矛盾（至少根据我目前的理解）。
首先，标准做法似乎表明移动应用程序本身并不是私有的，因此，不应使用利用反向通道的标准流程。作为解决方法，可以使用 PKCE 扩展（并利用内置设备浏览器而不是 Web 视图，因此令牌和敏感信息不太可能泄露）。
但是，在协议的动态客户端注册规范中，还提到移动应用程序应使用这种客户端注册方法来获取有效的客户端 ID 和客户端密码...但是，为什么我们要在在前面的部分中，已经确定移动应用程序确实是 public 客户端，并且不能信任诸如客户端机密之类的机密信息（我们通过使用此 DCR 机制获得...
所以，我有什么不明白的？这两件事似乎相互矛盾。有人声称移动应用 public 不应该被秘密信任。然而，在推荐的 DCR 机制中，我们为他们分配了我们刚刚建立的秘密，他们无法信任。
谢谢。
有点晚了，但希望对您有所帮助。所以 OAuth2.0 协议的一部分是两个组件，client_id 和客户端密码。客户端和服务器必须就协议之外的这两个值达成一致，即在协议开始之前。通常，过程如下。客户端使用 out-of-bound 通信通道与授权服务器通信以获取这些值并在服务器上注册。这种客户端注册可以通过两种方式进行，静态和动态。静态意味着 client_id 和秘密确实发生了变化，即客户端在向服务器注册时会获得一次。动态客户端注册是指每次客户端要使用协议时注册一个client_id的过程，即每次都会为他生成一个client secret（也是通过outbound通信）。
现在，为什么要使用动态注册？
动态客户端注册更适合跨复制的授权服务器管理客户端。, 最初的 OAuth 用例围绕 single-location APIs，例如来自提供 Web 服务的公司的案例。这些 API 需要专门的客户与他们交谈，而这些客户只需要与一个 API 提供者交谈。在这些情况下，期望客户端开发人员努力向 API 注册他们的客户端似乎不是不合理的，因为只有一个提供商。
动态客户端注册是否提供任何安全优势？
不，如果与 JavaScript 或本机移动客户端一起使用，两者都容易受到攻击（可以检查 JavaScript 客户端，并且可以反编译移动应用程序）。因此，它们都需要 PKCE 作为额外的安全层。
我正在开发自己的 OAuth2 + OpenID Connect 实现。我对如何处理本机（特别是移动）客户端的 OAuth 流程感到有点困惑。到目前为止，我发现我需要使用身份验证代码流。然而，根据我的研究，有一些细节似乎相互矛盾（至少根据我目前的理解）。
首先，标准做法似乎表明移动应用程序本身并不是私有的，因此，不应使用利用反向通道的标准流程。作为解决方法，可以使用 PKCE 扩展（并利用内置设备浏览器而不是 Web 视图，因此令牌和敏感信息不太可能泄露）。
但是，在协议的动态客户端注册规范中，还提到移动应用程序应使用这种客户端注册方法来获取有效的客户端 ID 和客户端密码...但是，为什么我们要在在前面的部分中，已经确定移动应用程序确实是 public 客户端，并且不能信任诸如客户端机密之类的机密信息（我们通过使用此 DCR 机制获得...
所以，我有什么不明白的？这两件事似乎相互矛盾。有人声称移动应用 public 不应该被秘密信任。然而，在推荐的 DCR 机制中，我们为他们分配了我们刚刚建立的秘密，他们无法信任。
谢谢。
有点晚了，但希望对您有所帮助。所以 OAuth2.0 协议的一部分是两个组件，client_id 和客户端密码。客户端和服务器必须就协议之外的这两个值达成一致，即在协议开始之前。通常，过程如下。客户端使用 out-of-bound 通信通道与授权服务器通信以获取这些值并在服务器上注册。这种客户端注册可以通过两种方式进行，静态和动态。静态意味着 client_id 和秘密确实发生了变化，即客户端在向服务器注册时会获得一次。动态客户端注册是指每次客户端要使用协议时注册一个client_id的过程，即每次都会为他生成一个client secret（也是通过outbound通信）。
现在，为什么要使用动态注册？
动态客户端注册更适合跨复制的授权服务器管理客户端。, 最初的 OAuth 用例围绕 single-location APIs，例如来自提供 Web 服务的公司的案例。这些 API 需要专门的客户与他们交谈，而这些客户只需要与一个 API 提供者交谈。在这些情况下，期望客户端开发人员努力向 API 注册他们的客户端似乎不是不合理的，因为只有一个提供商。
动态客户端注册是否提供任何安全优势？
不，如果与 JavaScript 或本机移动客户端一起使用，两者都容易受到攻击（可以检查 JavaScript 客户端，并且可以反编译移动应用程序）。因此，它们都需要 PKCE 作为额外的安全层。