Excellent point! The specs (OAuth2 and OIDC) are completely silent on
what should happen if an HTTP transport error occurs. Maybe that whole
space should have it's own blog post:)
Regardless of the OAuth2/OIDC error code, clients already have to deal
with HTTP codes like 503 "Service Unavailable", or 504 "Gateway timed
out" which will not have any of the OAuth2 level error response data.
Given a rate-limiting condition is a transport condition and not a
protocol condition, I'd be fine with not returning any protocol error
data and require the client to handle the transport conditions correctly.
Thanks,
George
On 2/22/19 10:34 AM, Evert Pot wrote:
On 2019-02-22 10:29 a.m., George Fletcher wrote:
I believe Torsten proposed an "authentication_failed" error response
in a different context. Possibly we could use that?
Alternatively, OpenID Connect defines a 'login_required' error that
could work in this context as well. It doesn't fit the semantic as
defined in the OIDC spec, but as an error would work.
If we need to use an existing OAuth2 error code, then I'd recommend
'invalid_request' in that the request is invalid because there are
too many of them which is indicated by the 429 HTTP error code.
What benefit would a specific request body serve?
Should a client behave differently if they got a 429 from an
intermediate oauth2-unaware proxy vs an oauth2 server that emits this
body?
On 2/22/19 9:53 AM, Aaron Parecki wrote:
HTTP 429 sounds fine for the HTTP response code, but what about the
OAuth error code string? "invalid_grant" seems closest but doesn't
sound right because if the app tries the same request again later it
would be valid.
On Fri, Feb 22, 2019 at 6:02 AM George Fletcher <[email protected]
<mailto:[email protected]>> wrote:
+1 for using 429
On 2/22/19 2:09 AM, David Waite wrote:
I don’t believe that any of the currently registered error
codes are appropriate for indicating that the password request
is invalid, let alone a more specific behavior like rate limiting.
It is also my opinion that 400 Bad Request shouldn’t be used
for known transient errors, but rather for malformed requests -
the request could very well be correct (and have the correct
password), but it is being rejected due to temporal limits
placed on the client or network address/domain.
So I would propose a different statuses such 401 to indicate
the username/password were invalid, and either 429 (Too many
requests) or 403 (Forbidden) when rate limited or denied due to
too many attempts. Thats not to say that the body of the
response can’t be an OAuth-format JSON error, possibly with a
standardized code - but again I don’t think the currently
registered codes would be appropriate for conveying that.
That said, I don’t know what interest there would be in
standardizing such codes, considering the existing
recommendations against using this grant type.
-DW
On Feb 21, 2019, at 10:57 PM, Aaron Parecki <[email protected]
<mailto:[email protected]>> wrote:
The OAuth password grant section mentions taking appropriate
measures to rate limit password requests at the token
endpoint. However the error responses section (
https://tools.ietf.org/html/rfc6749#section-5.2) doesn't
mention an error code to use if the request is being rate
limited.. What's the recommended practice here? Thanks!
Aaron
--
----
Aaron Parecki
aaronparecki.com <http://aaronparecki.com/>
@aaronpk <http://twitter.com/aaronpk>
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
--
----
Aaron Parecki
aaronparecki.com <http://aaronparecki.com>
@aaronpk <http://twitter.com/aaronpk>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
