Subject: [OAUTH-WG] Correct error code for rate limiting?

From: Aaron Parecki <[email-masked]>
Date: Thu, 21 Feb 2019 21:57:08 -0800

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
@aaronpk <http://twitter.com/aaronpk>

---

From: David Waite <[email-masked]>
Date: Fri, 22 Feb 2019 00:09:09 -0700

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-masked]> 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 <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/>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: George Fletcher <[email-masked]>
Date: Fri, 22 Feb 2019 09:02:48 -0500

+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-masked] 
>> <mailto:[email-masked]>> 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
>> [email-masked] <mailto:[email-masked]>

---

From: Aaron Parecki <[email-masked]>
Date: Fri, 22 Feb 2019 06:53:05 -0800

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-masked]> wrote:

> appropriate for indicating that the password request is invalid, let alone
> a more specific behavior like rate limiting.
>
> 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.
>
> 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
>
> code to use if the request is being rate limited.. What's the recommended
> practice here? Thanks!
>
> Aaron
>
> --
> ----
> Aaron Parecki
> aaronparecki.com
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
> --
----
Aaron Parecki
aaronparecki.com

---

From: George Fletcher <[email-masked]>
Date: Fri, 22 Feb 2019 10:29:47 -0500

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.

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-masked] 
> <mailto:[email-masked]>> wrote:
>
>     +1 for using 429
>
>
>>     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.
>>
>>     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
>>
>>>     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>

---

From: Evert Pot <[email-masked]>
Date: Fri, 22 Feb 2019 10:34:23 -0500

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?
>

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?

>>>     password), but it is being rejected due to temporal limits
>>>     placed on the client or network address/domain.
>>>
>>>     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
>>>>     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

---

From: George Fletcher <[email-masked]>
Date: Fri, 22 Feb 2019 11:02:13 -0500

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:
>> 'invalid_request' in that the request is invalid because there are 
>> too many of them which is indicated by the 429 HTTP error code.
>
>>>>     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
>>>>     So I would propose a different statuses such 401 to indicate
>>>>     the username/password were invalid, and either 429 (Too many
>>>>>     measures to rate limit password requests at the token
>>>>>     endpoint. However the error responses section (