我一直在广泛阅读有关OAuth和OpenID Connect的内容,但这个问题专门针对OAuth2资源所有者密码授予(也就是OAuth2资源所有者凭据授权,即OAuth2密码授权)
一些资源(如Justin Richer的书"OAuth2 in Action")说 not to use OAuth2 Resource Owner Password Grant for authentication - 参见本书第6.1.3节 .
其他好的资源,如下面的 all say we can use the OAuth2 Resource Owner Password Grant to essentially authenticate users via trusted apps :
-
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/
但是我很难理解为什么我们不应该使用OAuth2资源所有者密码授权作为成功验证的基本证据?
我对资源所有者密码授予流程的理解是最终用户向可信客户端(我的本机应用程序)提供了用户名和密码,然后将其转发到我的API的OAuth服务器并交换它以获取访问令牌(以及可选的刷新令牌)它可以用于其他经过身份验证的API endpoints . 本机应用程序不保存用户名/密码,而是依赖于短期访问令牌和更长寿命的刷新令牌(以便在它们到期时获取新的访问令牌) .
为什么我甚至需要OpenID Connect?为什么我不能仅使用OAuth2资源所有者密码授权作为身份验证机制?
Both the native app and the API are developed by the same person (me).
任何解释都会受到欢迎 . 谢谢 .
3 回答
如果服务器和客户端应用程序都是您的,则可以使用“资源所有者密码凭据”流来获取访问令牌 .
如果服务器是您的,但客户端应用程序不是您的(=如果客户端应用程序是由第三方供应商开发的),则您的服务器不应允许客户端应用程序使用资源所有者密码凭据流 . 这是因为资源所有者密码凭据流无法阻止第三方客户端应用程序窃取最终用户的密码 .
OpenID Connect规范未描述OpenID提供程序应如何对最终用户进行身份验证 . 相反,规范描述了OpenID提供程序应如何生成ID令牌 . 由于ID令牌包含OpenID提供程序生成的签名,因此接收ID令牌的客户端应用程序可以验证ID令牌是否已由OpenID提供程序真正签名 .
也就是说,OpenID Connect是关于如何使最终用户身份验证的结果可验证的规范 . 它不是关于如何验证最终用户的规范 .
资源所有者凭证授予比任何其他授权具有更高的风险并且违背协议的目的,其目的在于
hide user credentials from the client application
.对于本机应用程序 - 您是对的,它可以分析您的应用程序并从中检索用户密钥 . 此外,我可以想象有人会创建一个与您类似的应用程序,并从中获取用户的密码,并执行其他潜在的恶意操作,而无需用户注意 .
我建议你阅读OAuth2和OpenID Connect的规格 . 为什么不使用资源所有者密码授权(来自OAuth2 spec):
OAuth 2.0,无论授权类型如何,is not an authentication protocol .
OpenID Connect是基于OAuth 2.0构建的身份验证协议
这些是一些引用(有几个来自编写OAuth 2.0和/或OpenID Connect的人):
http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html
https://twitter.com/ve7jtb/status/740650395735871488
https://nat.sakimura.org/2013/07/05/identity-authentication-oauth-openid-connect/
http://ldapwiki.com/wiki/OAuth%202.0%20NOT%20an%20Authentication%20protocol