我已经广泛阅读有关OAuth和OpenID Connect的内容，但此问题专门针对OAuth2资源所有者密码授予（也就是OAuth2资源所有者凭据授权，即OAuth2密码授权）
一些资源（如书＆＃34; OAuth2 in Action＆＃34;由Justin Richer撰写）说不使用OAuth2资源所有者密码授予进行身份验证 - 请参阅本书第6.1.3节
以下其他优秀资源所有人都说我们可以使用OAuth2资源所有者密码授予从本质上通过受信任的应用验证用户：
但我很难理解为什么我们不应该使用OAuth2资源所有者密码授予作为成功验证的基本证据？
我对资源所有者密码授予流程的理解是，最终用户向受信任的客户端（我的本机应用程序）提供了用户名和密码，然后将其转发到我的API的OAuth服务器并进行交换。一个访问令牌（和可选的刷新令牌），它可以用于其他经过身份验证的API端点。本机应用程序不会保存用户名/密码，而是依赖于短期访问令牌和更长寿的刷新令牌（以便在它们过期时获取新的访问令牌）。
为什么我甚至需要OpenID Connect？为什么我不能仅使用OAuth2资源所有者密码授权作为身份验证机制？
本机应用和API均由同一个人（我）开发。
欢迎任何解释。谢谢。
答案 0 :(得分：1)
如果服务器和客户端应用程序都是您的，则可以使用“资源所有者密码凭据”流来获取访问令牌。
如果服务器是您的，但客户端应用程序不是您的（=如果客户端应用程序是由第三方供应商开发的），则您的服务器不应允许客户端应用程序使用资源所有者密码凭据流。这是因为资源所有者密码凭据流无法阻止第三方客户端应用程序窃取最终用户的密码。
OpenID Connect规范未描述OpenID提供商应如何对最终用户进行身份验证。相反，规范描述了OpenID提供程序应如何生成ID令牌。由于ID令牌包含OpenID提供程序生成的签名，因此接收ID令牌的客户端应用程序可以验证ID令牌是否已由OpenID提供程序真正签名。
也就是说，OpenID Connect是一个关于如何使最终用户身份验证的结果可以验证的规范。它不是关于如何验证最终用户的规范。
答案 1 :(得分：1)
资源所有者凭证授予比任何其他授予的风险更高，并且违反协议的目的，其目的是hide user credentials from the client application。
对于原生应用 - 您是对的，可以分析您的应用并从中检索用户密钥。此外，我可以想象有人会创建一个与您类似的应用程序，并从中获取用户的密码，并执行其他潜在的恶意操作，而无需用户注意。
我建议您阅读OAuth2和OpenID Connect的规格。 为什么不使用资源所有者密码授权（来自OAuth2 spec）：
资源所有者密码凭据授予类型通常用于 遗产或迁移原因。它降低了存储的整体风险 客户端的用户名和密码，但不消除需要 将高权限凭据公开给客户端。
此授权类型比其他授权类型具有更高的风险，因为 它维护了该协议试图避免的密码反模式。 客户端可能滥用密码，或密码可以 无意中向攻击者披露（例如，通过日志文件或 客户保留的其他记录。）
此外，因为资源所有者无法控制 授权过程（资源所有者的参与何时结束 它将其凭据交给客户端），客户端可以获得 访问具有比资源所需范围更广的范围的令牌 所有者。授权服务器应考虑范围和 通过此授权类型发出的访问令牌的生命周期。
授权服务器和客户端应该尽量减少使用此授权 尽可能键入并使用其他授权类型。
答案 2 :(得分：0)
OAuth 2.0，无论授权类型如何is not an authentication protocol。
OpenID Connect是基于OAuth 2.0构建的身份验证协议
这些是一些参考资料（其中一些来自编写OAuth 2.0和/或OpenID Connect的人员）：