当资源所有者无法在OAuth 2.0中对自己进行身份验证时，授权服务器应该执行什么操作？

Question

我正在开发一个应用程序，我正在尝试将用户数据保存到第三方服务。该服务允许我访问用户＆＃39;通过OAuth的资源。我已经完成了OAuth流程的实现，它的工作原理如下（没有错误发生时）：

1. 我将用户重定向到服务提供商的身份验证页面，在URL中提供以下参数：
   ?redirect_uri=[my_redirect_uri]&client_id=[my_client_id]&response_type=code
2. 用户验证他/她自己
3. 该服务将用户重定向到redirect_uri，并在URL参数中传递授权码：code=[authorization_code]
4. 我从access_token
获得auth_code
5. 我现在可以访问用户数据

您可以看到图表here。

我发现对于此特定服务，当用户无法对自己进行身份验证时（步骤2），授权服务器会立即将User-Agent重定向到我的redirect_uri并在我获得的URL参数中error=access_denied。

我发现这不是一个用户友好的体验，因为用户可能会输入错误或只是忘记他/她的凭据。

我检查了OAuth 2.0 Authorization Framework RFC。似乎资源所有者的身份验证失败没有任何协议。我在RFC中看到存在客户端身份验证失败或授权失败的协议。但是，未说明授权服务器在无法验证资源所有者时应如何响应。

我尝试使用Facebook OAuth登录Medium进行了自己的研究。我看到，当我登录失败时，我仍然在Facebook身份验证页面，Facebook通知我，我的凭据是错误的。我可以输入错误的凭据最多3次，之后，流将中断（与OAuth关联的URL中的参数消失）。当我输入正确的凭据并拒绝中，以访问我的个人资料时，我被重定向到中等error=access_denied

Facebook最佳做法是什么？是否有允许资源所有者身份验证的尝试次数的策略？授权服务器无法验证资源所有者时的正确响应是什么？

Answer 1

error=access_denied的响应实际上符合OAuth2规范。使用授权代码授权时授权端点的错误响应部分（4.1.2.1.）列出了几个可能的错误代码，并说明了access_denied的以下内容：

  

ACCESS_DENIED
  资源所有者或授权服务器拒绝了该请求。

_{（重点是我的）}

感觉不正确的是立即将无效凭据视为错误，并且不允许用户重试密码输入以保护偶尔的拼写错误。然而，这仍然是授权服务器的判断，在规范中没有（我知道）规定何时应该返回错误，因此不允许用户重试，尽管规范可以，可能是不好的用户体验

Answer 2

OAuth仅对此案例进行了重新审核，但并未限制资源所有者身份验证允许的尝试次数。

如果授权服务器观察到多次尝试交换 授权服务器应该尝试撤销已经授权的所有访问令牌。