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 protected]>: > 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 >> >> 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 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 >> 2-276-4705 (T/L) >> [email protected] >> >> >> >> >> >> >> From: Santiago Pérez <[email protected]> >> To: [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] >> >> >> >> >> 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] >> 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
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
