【发布时间】：2015-01-06 11:04:33
【问题描述】：
OIDC 不支持资源所有者密码凭据授予。为什么？我的一些客户端是安全设备，可以安全地维护凭据......这些凭据可用于获取 access_token。我还能使用 OpenID Connect 吗？
【问题讨论】：
【发布时间】：2015-01-06 11:04:33
【问题描述】：
规范中没有明确说明，但 OpenID Connect 支持所有 OAuth 2.0 流程，因为它是 OAuth 2.0 的扩展。
规范讨论了涉及浏览器重定向的流程，因为它们更常见、更安全且不那么脆弱，因为资源所有者凭据仅支持用户名和密码，并且仅在 OAuth 2 规范中以实现向后兼容性。在真正的 SSO 系统中，您希望从 OP/IDP 验证用户的方法中抽象出来。涉及浏览器是一种方法。
但您的里程可能会有所不同。支持特定的 OP/AS 软件和客户端库。
FWIW：您应该寻求获取 id_token 而不是 access_token。
【讨论】：
-
谢谢！ “在真正的 SSO 系统中，您希望从在 OP/IDP 验证用户的方法中抽象出来”。你能详细说明一下吗？我什至想对我的安全设备使用 SSO……我是否错过了重点？
-
您通常不希望使用身份提供者可以使用的所有可能的身份验证机制来扩展您的客户端；想象一下，例如引入第二因素身份验证：您的客户应该关心实现它，只需将其留给浏览器
OpenID Connect 执行身份验证以登录最终用户或 确定最终用户已经登录。 OpenID Connect 将服务器执行的身份验证结果返回给 以安全的方式访问客户端，以便客户端可以依赖它。
对于隐式和授权代码授权类型流，如果最终用户未登录，则无法发布 ID 令牌。在这种情况下，授权服务器可以向依赖方确认最终用户已登录在。 但是对于资源所有者授权类型流程，授权服务器无法确认最终用户是否已登录。即使最终用户未登录，您也可以发出访问令牌。
【讨论】：
-
这个答案令人困惑：用户的身份验证始终由授权服务器执行，甚至/也在资源所有者密码凭证 (ROPC) 流程中。不同之处在于，在 ROPC 中，客户端“看到”资源所有者的用户名/密码，这与其他流程不同，这违背了像 OpenID Connect 这样的联合 SSO 协议的主要目的，其中身份验证机制和凭据应该独立于客户端/应用程序。因此，您不会在 OpenID Connect 中看到太多 ROPC 的使用，但在企业内部用例中可能会有例外。
-
-1 您的引述并未以任何方式解释为何在 OIDC 中无法使用 ROPC 流程。就像@HansZ。也就是说，授权服务器仍然在 ROPC 流程中进行身份验证。
-
感谢您的 cmets。我更新了我的答案，因为它不是很清楚。