Subject: [OAUTH-WG] Throttling error using resource owner password credentials grant or authorization code grant

From: Santiago Pérez <[email-masked]>
Date: Tue, 16 Jul 2013 18:30:43 +0200

Dear all,

We are implementing a OAuth 2.0 server and there is a point that is not
clear for me in the RFC 6749.

What error should we return when the maximum number of attempts for
resource owner credentials is exceeded? I can not see any suitable error in
the current RFC.

We are implementing a policy for controlling this X attempts per period
(e.g.: 3 times/15 minutes)

Thanks for your answer.

Kind Regards,

Santiago Pérez

---

From: Justin Richer <[email-masked]>
Date: Wed, 17 Jul 2013 13:53:52 -0400

Rate limiting an HTTP connection is not something OAuth-specific. HTTP 
error code "429 Too Many Requests" is probably your best bet for getting 
clients to behave:

http://tools.ietf.org/html/rfc6585#section-4

  -- Justin

On 07/16/2013 12:30 PM, Santiago Pérez wrote:
> Dear all,
>
> We are implementing a OAuth 2.0 server and there is a point that is 
> not clear for me in the RFC 6749.
>
> resource owner credentials is exceeded? I can not see any suitable 
> error in the current RFC.
>
> We are implementing a policy for controlling this X attempts per 
> period (e.g.: 3 times/15 minutes)
>
> Thanks for your answer.
>
> Kind Regards,
>
> Santiago Pérez
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Todd W Lainhart <[email-masked]>
Date: Wed, 17 Jul 2013 11:57:04 -0400

Why wouldn't you return an HTTP-level status code of 401, with perhaps 
some text describing the account lock-out?  Or a 403 if you wanted a 
separate lockout status code.

Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
[email-masked]

From:   Santiago Pérez <[email-masked]>
To:     [email-masked], 
Date:   07/17/2013 11:09 AM
Subject:        [OAUTH-WG] Throttling error using resource owner password 
credentials grant or authorization code grant
Sent by:        [email-masked]

Dear all,

What error should we return when the maximum number of attempts for 
resource owner credentials is exceeded? I can not see any suitable error 
in the current RFC.

Thanks for your answer.

Kind Regards,

Santiago Pérez_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: André DeMarre <[email-masked]>
Date: Thu, 18 Jul 2013 15:21:33 -0700

This question exposes a shortcoming of the final spec. After implementing
an authorization server, I've formed the opinion that the spec doesn't
define clearly enough the auth server's behavior at the token endpoint.
Implementers do not know what discretion they are entitled when trying to
reconcile OAuth behavior with scenarios that are outside the scope of the
OAuth spec.

The original question about throttling authentication attempts is a perfect
example. Section 5.2 (token endpoint error response) is very specific, but
it doesn't give any allowance for handling errors that are not
OAuth-specific. So if resource owner credentials cannot be accepted because
of previous unsuccessful attempts, does that mean the response at the token
endpoint is not an OAuth response at all and the server is free to respond
with HTML if it so chooses? It could be that the client has done nothing
wrong and is following the spec perfectly, so it seems appropriate that the
auth server should send an error response that complies with Section 5.2.
None of the defined error codes are appropriate, so I suppose the server
could use an unregistered error code as permitted by Secion 8.5. Is that
correct?

I'm inclined to agree with Justin that 429 is a good HTTP status code here,
but the spec is unclear about the use of 4xx status codes beyond 400 and
401. In March I asked a similar (unanswered) question regarding the use of
405: http://www.ietf.org/mail-archive/web/oauth/current/msg11192.html

The crux is that authorization server implementers are given no direction
when solving problems in that gray area where the problem is outside the
scope of OAuth, but they still want their server to respond in a way that
is comprehensible by OAuth clients. If you think I'm looking at this wrong,
I'd like to hear about it.

http://tools.ietf.org/html/rfc6749#section-5.2
http://tools.ietf.org/html/rfc6749#section-8.5

Regards,
Andre DeMarre

On Wed, Jul 17, 2013 at 8:57 AM, Todd W Lainhart <[email-masked]>wrote:

>  *
> 550 King Street, Littleton, MA 01460-1250**
> 1-978-899-4705
> 2-276-4705 (T/L)
> [email-masked]*
>
>
>
>
> ------------------------------
>
>
>
> Dear all,
>

---

From: Todd W Lainhart <[email-masked]>
Date: Fri, 19 Jul 2013 10:20:30 -0400

I agree that 429 seems to be the more appropriate status code for this 
case - I wasn't aware of these extensions.

Re how to reconcile application errors/status that are outside the OAuth 
domain, I've also struggled with that a bit.  My current position is to 
try and fit the error response within the OAuth error reporting framework 
as much as is possible and reasonable.

For example, with the account lockout problem, I would return some 
HTTP-level status code (401, 403, or 429), using the OAuth error schema in 
the response body.  The error_code might be invalid_request, and then the 
body describing exactly what the problem was.  I'm a bit conflicted on 
this, but in practice, I've found that most programmatic clients will not 
disambiguate the 401/403/429, and just want to know if this was an 
authentication problem, and what text to return to the user.  The problem 
then becomes what text to return, as the text in error_description is 
US_ASCII, and may not be appropriate for the locale of the client.  So it 
may be that a custom error_code is the way out.

Todd Lainhart
Rational software
IBM Corporation

From:   André DeMarre <[email-masked]>
To:     Todd W Lainhart/Lexington/IBM@IBMUS, Justin Richer 
<[email-masked]>, 
Cc:     Santiago Pérez <[email-masked]>, OAuth WG <[email-masked]>
Date:   07/18/2013 06:22 PM
Subject:        Re: [OAUTH-WG] Throttling error using resource owner 
password credentials grant or authorization code grant

The original question about throttling authentication attempts is a 
perfect example. Section 5.2 (token endpoint error response) is very 
specific, but it doesn't give any allowance for handling errors that are 
not OAuth-specific. So if resource owner credentials cannot be accepted 
because of previous unsuccessful attempts, does that mean the response at 
the token endpoint is not an OAuth response at all and the server is free 
to respond with HTML if it so chooses? It could be that the client has 
done nothing wrong and is following the spec perfectly, so it seems 
appropriate that the auth server should send an error response that 
complies with Section 5.2. None of the defined error codes are 
appropriate, so I suppose the server could use an unregistered error code 
as permitted by Secion 8.5. Is that correct?

I'm inclined to agree with Justin that 429 is a good HTTP status code 
here, but the spec is unclear about the use of 4xx status codes beyond 400 
and 401. In March I asked a similar (unanswered) question regarding the 
use of 405: 
http://www.ietf.org/mail-archive/web/oauth/current/msg11192.html

The crux is that authorization server implementers are given no direction 
when solving problems in that gray area where the problem is outside the 
scope of OAuth, but they still want their server to respond in a way that 
is comprehensible by OAuth clients. If you think I'm looking at this 
wrong, I'd like to hear about it.

Regards,
Andre DeMarre

On Wed, Jul 17, 2013 at 8:57 AM, Todd W Lainhart <[email-masked]> 
wrote:
Why wouldn't you return an HTTP-level status code of 401, with perhaps 
some text describing the account lock-out?  Or a 403 if you wanted a 
separate lockout status code.

Todd Lainhart
Rational software
IBM Corporation

Dear all,

Thanks for your answer.

Kind Regards,

---

From: Santiago Pérez <[email-masked]>
Date: Mon, 29 Jul 2013 13:57:49 +0200

Thanks for your answers.

I feel that there is not a clear solution my question/problem currently.

I don't think that throttling is out of the scope of OAuth 2.0.

If resource owner password credentials it is defined as a OAuth 2.0
mechanism, the expected behaviour when the access is blocked because a
exceed the allowed resource owner credential attempts issue should be
specified to ensure that the implemented clients have a proper behaviour to
this situation, informing to the resource owner properly of the current
problem.

Looking in the specification, I see the access_denied error specified in
4.1.2.1 as a good choice but it is only specified for authorization
requests.

 access_denied
               The resource owner or authorization server denied the
               request.

I don't know why this error is not also specified for token requests. Is
there any reason? Has the authorization server any option to denied the
generation of a token when a client asks for a token? What is the error
that should be used in this case?

In the throttling scenario, the authorization server is denying the request
because the maximun number of attemps has been exceeded.

This error could be returned as:

{ "error": "access_denied", "error_description": "maximum number of
attempts exceeded" }

I don't want to use something that is not in the specification, but my
feeling is that there is a lack at this point.

Best Regards,

Santiago Pérez
Telefónica Digital

2013/7/19 Todd W Lainhart <[email-masked]>

> domain, I've also struggled with that a bit.  My current position is to try
> and fit the error response within the OAuth error reporting framework as
> much as is possible and reasonable.
>
> To:        Todd W Lainhart/Lexington/IBM@IBMUS, Justin Richer <
> [email-masked]>,
> to respond with HTML if it so chooses? It could be that the client has done
> nothing wrong and is following the spec perfectly, so it seems appropriate
> that the auth server should send an error response that complies with
> Section 5.2. None of the defined error codes are appropriate, so I suppose
> the server could use an unregistered error code as permitted by Secion 8.5.
> Is that correct?
>
> and 401. In March I asked a similar (unanswered) question regarding the use
> of 405: *http://www.ietf.org/mail-archive/web/oauth/current/msg11192.html*<http://www.ietf.org/mail-archive/web/oauth/current/msg11192.html>
>
> *http://tools.ietf.org/html/rfc6749#section-5.2*<http://tools.ietf.org/html/rfc6749#section-5.2>
> *http://tools.ietf.org/html/rfc6749#section-8.5*<http://tools.ietf.org/html/rfc6749#section-8.5>
>
> Regards,
> Andre DeMarre
>
>
> On Wed, Jul 17, 2013 at 8:57 AM, Todd W Lainhart <[email-masked]*<[email-masked]>>
> wrote:
> **1-978-899-4705* <1-978-899-4705>*
> 2-276-4705 (T/L)**
> [email-masked]* <[email-masked]>
>
>
>
>
>
> From:        Santiago Pérez <[email-masked]*<[email-masked]>
> >
> To:        [email-masked]* <[email-masked]>,
> Sent by:        [email-masked]* <[email-masked]>
> OAuth mailing list*
> [email-masked]* <[email-masked]>*
> **https://www.ietf.org/mailman/listinfo/oauth*<https://www.ietf.org/mailman/listinfo/oauth>
>
>
> OAuth mailing list*
> [email-masked]* <[email-masked]>*
> **https://www.ietf.org/mailman/listinfo/oauth*<https://www.ietf.org/mailman/listinfo/oauth>
>
>
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 29 Jul 2013 15:45:24 +0200

Hi Santiago,

we use the "invalid_grant" error code in conjunction with further information encoded into the error description (including lock out time) for such cases. 

The example error description

"invalid username or password; account locked temporarily; 10 s"

tells the client that the user account is locked for 10 seconds.

I know this is not the best design but the only "spec-compliant" way we came up with. I think there is room for improvements and would suggest we discuss this in the WG.

regards,
Torsten.

Am 29.07.2013 um 13:57 schrieb Santiago Pérez <[email-masked]>:

> If resource owner password credentials it is defined as a OAuth 2.0 mechanism, the expected behaviour when the access is blocked because a exceed the allowed resource owner credential attempts issue should be specified to ensure that the implemented clients have a proper behaviour to this situation, informing to the resource owner properly of the current problem.
> 
> Looking in the specification, I see the access_denied error specified in 4.1.2.1 as a good choice but it is only specified for authorization requests.
> 
>  access_denied
> I don't know why this error is not also specified for token requests. Is there any reason? Has the authorization server any option to denied the generation of a token when a client asks for a token? What is the error that should be used in this case?
> 
> In the throttling scenario, the authorization server is denying the request because the maximun number of attemps has been exceeded.
> 
> { "error": "access_denied", "error_description": "maximum number of attempts exceeded" }
> 
> I don't want to use something that is not in the specification, but my feeling is that there is a lack at this point.
> 
> Best Regards,
> 
> Santiago Pérez
> Telefónica Digital
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> I agree that 429 seems to be the more appropriate status code for this case - I wasn't aware of these extensions. 
>> 
>> Re how to reconcile application errors/status that are outside the OAuth domain, I've also struggled with that a bit.  My current position is to try and fit the error response within the OAuth error reporting framework as much as is possible and reasonable. 
>> 
>> For example, with the account lockout problem, I would return some HTTP-level status code (401, 403, or 429), using the OAuth error schema in the response body.  The error_code might be invalid_request, and then the body describing exactly what the problem was.  I'm a bit conflicted on this, but in practice, I've found that most programmatic clients will not disambiguate the 401/403/429, and just want to know if this was an authentication problem, and what text to return to the user.  The problem then becomes what text to return, as the text in error_description is US_ASCII, and may not be appropriate for the locale of the client.  So it may be that a custom error_code is the way out.
>> 
>> 
>> 
>> 
>> Todd Lainhart
>> Rational software
>> IBM Corporation
>> To:        Todd W Lainhart/Lexington/IBM@IBMUS, Justin Richer <[email-masked]>, 
>> Subject:        Re: [OAUTH-WG] Throttling error using resource owner password credentials grant or authorization code grant 
>> 
>> 
>> 
>> This question exposes a shortcoming of the final spec. After implementing an authorization server, I've formed the opinion that the spec doesn't define clearly enough the auth server's behavior at the token endpoint. Implementers do not know what discretion they are entitled when trying to reconcile OAuth behavior with scenarios that are outside the scope of the OAuth spec. 
>> 
>> The original question about throttling authentication attempts is a perfect example. Section 5.2 (token endpoint error response) is very specific, but it doesn't give any allowance for handling errors that are not OAuth-specific. So if resource owner credentials cannot be accepted because of previous unsuccessful attempts, does that mean the response at the token endpoint is not an OAuth response at all and the server is free to respond with HTML if it so chooses? It could be that the client has done nothing wrong and is following the spec perfectly, so it seems appropriate that the auth server should send an error response that complies with Section 5.2. None of the defined error codes are appropriate, so I suppose the server could use an unregistered error code as permitted by Secion 8.5. Is that correct? 
>> 
>> I'm inclined to agree with Justin that 429 is a good HTTP status code here, but the spec is unclear about the use of 4xx status codes beyond 400 and 401. In March I asked a similar (unanswered) question regarding the use of 405: http://www.ietf.org/mail-archive/web/oauth/current/msg11192.html 
>> 
>> The crux is that authorization server implementers are given no direction when solving problems in that gray area where the problem is outside the scope of OAuth, but they still want their server to respond in a way that is comprehensible by OAuth clients. If you think I'm looking at this wrong, I'd like to hear about it. 
>> 
>> On Wed, Jul 17, 2013 at 8:57 AM, Todd W Lainhart <[email-masked]> wrote: 
>> Why wouldn't you return an HTTP-level status code of 401, with perhaps some text describing the account lock-out?  Or a 403 if you wanted a separate lockout status code.
>> 
>> 
>> 
>> Todd Lainhart
>> Rational software
>> IBM Corporation
>> Subject:        [OAUTH-WG] Throttling error using resource owner password credentials grant or authorization code grant 
>> We are implementing a OAuth 2.0 server and there is a point that is not clear for me in the RFC 6749.
>> 
>> What error should we return when the maximum number of attempts for resource owner credentials is exceeded? I can not see any suitable error in the current RFC.
>> 
>> We are implementing a policy for controlling this X attempts per period (e.g.: 3 times/15 minutes)
>> 
>> Thanks for your answer.
>> 
>> Kind Regards,
>>