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 protected]>
> 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
> 550 King Street, Littleton, MA 01460-1250**
> 1-978-899-4705
> 2-276-4705 (T/L)
> [email protected]*
>
>
>
>
> From: André DeMarre <[email protected]>
> To: Todd W Lainhart/Lexington/IBM@IBMUS, Justin Richer <
> [email protected]>,
> Cc: Santiago Pérez <[email protected]>, OAuth WG <
> [email protected]>
> Date: 07/18/2013 06:22 PM
> 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*<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-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 protected]*<[email protected]>>
> 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
> 550 King Street, Littleton, MA 01460-1250**
> **1-978-899-4705* <1-978-899-4705>*
> 2-276-4705 (T/L)**
> **[email protected]* <[email protected]>
>
>
>
>
>
> From: Santiago Pérez <*[email protected]*<[email protected]>
> >
> To: *[email protected]* <[email protected]>,
> 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 protected]* <[email protected]>
> ------------------------------
>
>
>
>
> 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_______________________________________________
> OAuth mailing list*
> **[email protected]* <[email protected]>*
> **https://www.ietf.org/mailman/listinfo/oauth*<https://www.ietf.org/mailman/listinfo/oauth>
>
>
> _______________________________________________
> OAuth mailing list*
> **[email protected]* <[email protected]>*
> **https://www.ietf.org/mailman/listinfo/oauth*<https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
