授权代码流与受信任应用程序的资源所有者密码授予

Posted 2023-03-08

【中文标题】授权代码流与受信任应用程序的资源所有者密码授予

【英文标题】：Authorization Code flow vs. resource owner password grant for trusted applications

【发布时间】：2017-06-26 20:24:10

【问题描述】：

我在尝试解决这个问题时遇到了问题... 授权代码流似乎是针对 3rd 方应用程序的，这就是为什么要让用户在授权服务器上授予应用程序权限。

当用户登录时，授权服务器会打开一个会话，以便用户在使用另一个 3rd 方应用程序时无需再次登录，但他们可能需要授予该应用程序权限，但不提供用户名/密码由于与授权服务器的会话cookie。

但是，对于身份提供者提供的受信任应用程序，他们通常使用资源所有者密码授予，因为他们不想要求用户授予应用程序权限。

这带来了一个问题，因为他们不再使用授权码流，他们不能再利用用户与授权服务器的会话 cookie……那么如何在这两种不同类型之间进行 SSO流量？

如果有一种方法可以在 AuthCode 中指定受信任的应用程序，这将不再是问题，但规范没有提供，我知道的任何 OAuth2 / OpenID 连接软件似乎也没有。

第二个是与 IDP 实现一些非标准的后端通信以获取会话信息...

我很想知道是否有人以其他创造性的方式解决了这个问题。

【问题讨论】：

大家都知道，我们专门使用 Auth0 V2 作为我们的 OAuth / OpenID Connect 实现

【参考方案1】：

正如您所建议的，资源所有者密码凭据 (ROPC) 授权类型的一个缺点是您必须向客户端提供用户名/密码凭据，这原则上会阻止客户端参与 SSO 系统。

您可以想出一种创造性的方法来获取 SSO 令牌/会话并将其传递给客户端，以通过“密码”字段中的 ROPC 流针对授权服务器进行验证，但您将重新发明以非标准方式自己授予授权代码授权类型。

简而言之：如果可以，请避免使用资源所有者密码凭据授予类型。它是 OAuth 2.0 中已弃用的授权类型，仅用于迁移场景。

【讨论】：

那么，您如何避免必须为您（作为和 IDP）拥有的应用程序提供用户同意？

大多数授权服务器 - 尤其是企业级服务器 - 都有一个配置选项来关闭每个客户端的同意。

虽然我同意应该尽量减少使用 ROPC 流程，但 OAuth 2.0 RFC 实际上并没有说它已被弃用。你有这个说法的来源吗？ （我问，因为我在其他地方也看到过这种说法，但从来没有来源 - 真的有兴趣找到一个！）