我广泛阅读了有关 OAuth 和 OpenID Connect 的内容,但这个问题具体是关于 OAuth2 资源所有者密码授予(又名 OAuth2 资源所有者凭据授予、又名 OAuth2 密码授予)
一些资源(例如 Justin Richer 所著的《OAuth2 in Action》一书)表示不要使用 OAuth2 资源所有者密码授予进行身份验证 - 请参阅书中的第 6.1.3 节。
其他好的资源(例如以下内容)都说我们可以使用 OAuth2 资源所有者密码授予来通过受信任的应用程序对用户进行身份验证:
- https://www.oauth.com/oauth2-servers/access-tokens/password-grant/
- https://stormpath.com/blog/the-ultimate-guide-to-mobile-api-security
- https://www.youtube.com/watch?v=FNz0Lupp8HM&index=60&list=PLyUlngzGzkztgTizxM6_zqiw8sRj7vBm0
- https://docs.apigee.com/api-services/content/implementing-password-grant-type
- https://oauth2.thephpleague.com/authorization-server/which-grant/
- https://aaronparecki.com/oauth-2-simplified/#others
但是我很难理解为什么我们不应该使用 OAuth2 资源所有者密码授予作为成功身份验证的本质证明?
我对资源所有者密码授予流程的理解是,最终用户向受信任的客户端(我的 native 应用程序)提供用户名和密码,然后将其转发到我的 API 的 OAuth 服务器并将其交换为访问 token (和可选的刷新 token ),它可用于其余经过身份验证的 API 端点。 native 应用程序不会保存用户名/密码,而是依赖于短期访问 token 和长期刷新 token (以便在过期时获取新的访问 token )。
为什么我需要 OpenID Connect?为什么我不能仅使用 OAuth2 资源所有者密码授予作为身份验证机制?
原生应用和 API 都是由同一个人(我)开发的。
欢迎任何解释。谢谢。
最佳答案
如果服务器和客户端应用程序都是您的,您可以使用资源所有者密码凭据流程来获取访问 token 。
如果服务器是您的,但客户端应用程序不是您的(= 如果客户端应用程序由第三方供应商开发),则您的服务器不应允许客户端应用程序使用资源所有者密码凭据流。这是因为资源所有者密码凭据流程无法阻止第三方客户端应用程序窃取最终用户的密码。
OpenID Connect 规范没有描述 OpenID 提供商应如何对最终用户进行身份验证。相反,该规范描述了 OpenID 提供商应如何生成 ID token 。由于 ID token 包含 OpenID 提供者生成的签名,因此接收 ID token 的客户端应用程序可以验证 ID token 是否确实由 OpenID 提供者签名。
也就是说,OpenID Connect 是一个关于如何使最终用户身份验证的结果可验证的规范。它不是关于如何验证最终用户身份的规范。
关于api - OAuth2 密码授予与 OpenID Connect,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/47447755/