17
votes

When using a Resource Owner Password grant type, it appears that an authorization server should respond with an HTTP 400 (Bad Request) status code if an access token could not be granted due to the resource owner entering an incorrect password. I have concluded this based on my understanding of RFC 6749 Section 5.2**, which says "The authorization server responds with an HTTP 400 (Bad Request) status code" in the case where a token could not be granted due to an invalid_grant. The reasons listed for an invalid_grant include the resource owner credentials being invalid.

Is my understanding correct? If so, why isn't HTTP 401 (Unauthorized) returned instead? With basic authentication an invalid password results in a 401. Why does OAuth 2.0 stipulate that 400 be returned? Is this because 401 is reserved for invalid client credentials?

** See http://tools.ietf.org/html/rfc6749#section-5.2

2

2 Answers

10
votes

I was wondering this as well, but it seems that a 401 response requires returning a WWW-Authenticate header in the response, which doesn't make sense in this OAuth flow. This is the link to the thread where the spec designers discuss this issue.

And for completeness (tl;dr): here is the specific message where Eran Hammer-Lahav from the OAuth team clarifies this issue.

8
votes

I guess it is implemented this way because the client are providing invalid data, i.e. (username, password, refresh token, etc..) the client is not trying to access protected resource, so he is receiving HTTP 400 to indicate that he should correct his inputs. Usually you should receive 401 when you trying to access protected resource using invalid or expired access token.