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

Question

我正在开发一个应用程序，并尝试将用户数据保存到第三方服务。该服务允许我通过 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. 我从 auth_code 获取 access_token
5. 我现在可以访问用户数据

您可以看到图表here .

我发现，对于此特定服务，当用户无法验证自己的身份(步骤 #2)时，授权服务器会立即将用户代理重定向到我的 redirect_uri 和 URL我收到 error=access_denied 参数。

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

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

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

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

Answer 1

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

access_denied
    The resource owner or authorization server denied the request.

_{(重点是我的)}

感觉不正确的是立即将无效凭据视为错误，并且不让用户重试密码输入以防止偶尔出现的拼写错误。然而，这由授权服务器自行决定，规范中没有任何内容(据我所知)规定何时应该返回错误，因此不允许用户重试，尽管规范可以接受，但可能是糟糕的用户体验.