The reason I used 400 in the flows (section 3) is that a 401 response requires returning a challenge [1]:
The request requires user authentication. The response MUST include a WWW-Authenticate header field. and we don't have a suitable challenge to return. We can't use the Token auth scheme here because the flow endpoints are not OAuth-protected resources. They use a mix of client credentials, user credentials, and verification codes. (Yes James, your proposal will solve this...) So instead of using a 401 without the required WWW-Authenticate header, I opted to use 400. EHL [1] http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-09#section-2.1 > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Robert Sayre > Sent: Tuesday, April 20, 2010 6:02 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] misuse of status code: 400 Bad Request > > The OAuth 2.0 draft uses HTTP status code 400 for access token requests that > are denied. > > Here is the definition of 400: > > The request could not be understood by the server due to malformed > syntax. The client SHOULD NOT repeat the request without > modifications. > > Status 400 should be used for malformed requests, not those that are > understood and rejected. 401 seems to be a better fit. > > -- > > Robert Sayre > > "I would have written a shorter letter, but I did not have the time." > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
