我在试图解决这个问题时遇到了问题...... 授权代码流似乎适用于第三方应用程序，这就是为什么让用户授权授权服务器上的应用程序。
当用户登录时，授权服务器会打开一个会话，以便用户在使用其他第三方应用程序时不需要再次登录，但是他们可能需要授予该应用程序权限，但不能提供由于与授权服务器的会话cookie而导致的用户名/密码。
但是，对于身份提供商提供的受信任应用程序，他们通常使用资源所有者密码授予，因为他们不希望要求用户授予应用程序权限。
这带来了一个问题，因为他们不再使用授权代码流，他们无法再利用用户与授权服务器的会话cookie ...那么如何在这两种不同的类型之间完成SSO流量？
如果有办法在AuthCode中指定受信任的应用程序，这将不再是一个问题，但规范不提供，也不是我所知道的任何OAuth2 / OpenID连接软件。< / p>
第二种方法是与IDP实施一些非标准的后端通信以获取会话信息......
我很想知道是否有人以其他创造性的方式解决了这个问题。
答案 0 :(得分：4)
正如您所建议的，资源所有者密码凭据（ROPC）授权类型的缺点是您必须向客户端提供用户名/密码凭据，这原则上会阻止客户端参与SSO系统。
您可以想出一种创造性的方法来获取SSO令牌/会话并将其传递给客户端，以通过针对授权服务器的“密码”字段中的ROPC流进行验证，但您将重新创建授权代码以非标准方式授予您自己的类型。
简而言之：如果可以，请避免使用资源所有者密码凭据授予类型。它是OAuth 2.0中不推荐使用的授权类型，仅用于迁移方案。