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
