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
