我正在开发一个应用程序,我正在尝试将用户数据保存到第三方服务 . 该服务允许我通过OAuth访问用户的资源 . 我已经完成了OAuth流的实现,它的工作原理如下(当没有错误发生时):
-
我将用户重定向到服务提供商的身份验证页面,在URL中提供以下参数:
?redirect_uri=[my_redirect_uri]&client_id=[my_client_id]&response_type=code
-
用户验证他/她自己
-
该服务将用户重定向到
redirect_uri
并在URL参数中传递授权码:code=[authorization_code]
-
我从
auth_code
获得access_token
-
我现在可以访问用户数据了
你可以看到图here .
我发现对于这个特定的服务,当用户无法验证他/她自己时(步骤#2),授权服务器立即将User-Agent重定向到我的 redirect_uri
,并且在URL参数中我得到 error=access_denied
.
我发现这不是一个用户友好的体验,因为用户可能会输入错误或只是忘记他/她的凭据 .
我检查了OAuth 2.0 Authorization Framework RFC . 似乎没有't any protocol on resource owner'的身份验证失败 . 我在RFC中看到存在客户端身份验证失败或授权失败的协议 . 但是,未说明授权服务器在无法验证资源所有者时应如何响应 .
我尝试使用Facebook OAuth登录Medium进行了自己的研究 . 我看到,当我登录失败时,我仍然在Facebook身份验证页面,Facebook通知我,我的凭据是错误的 . 我可以输入错误的凭据 up to 3 times ,之后,流将中断(与OAuth关联的URL中的参数消失) . 当我输入正确的凭据并拒绝中,以访问我的 Profiles ,然后,我被重定向到媒体与 error=access_denied
Facebook最好的做法是什么?是否有允许资源所有者身份验证的尝试次数的策略?授权服务器无法验证资源所有者时的正确响应是什么?
2 回答
error=access_denied
的响应实际上符合OAuth2规范 . 使用授权代码授权时,授权 endpoints 的错误响应部分(4.1.2.1.)列出了几个可能的错误代码,并说明了有关access_denied
的以下内容:(重点是我的)
感觉不正确的是立即将无效凭证视为错误,并且不允许用户重试密码输入以保护偶尔的拼写错误 . 但是,这仍然是授权服务器的判断,在规范中没有(我知道)规定何时应该返回错误,因此不允许用户重试,尽管规范可以,可能是不好的用户体验 .
OAuth仅对此案例进行了重新命名,它不限制资源所有者身份验证允许的尝试次数 .
如果授权服务器观察到多次尝试交换访问令牌的授权代码,授权服务器应该尝试撤销已经根据受损授权代码授予的所有访问令牌 .