Section 2.4.1 conflicts with HTTP. Both invalid_request and invalid_token should be used with a 401 response. 400 is not about poorly formatted authorization header, but about a bad protected resource request.
The way HTTP authentication works is that first the server authenticates the client. If *for any reason* authentication fails, it returns a 401. The error code can reflect the exact reason (for example, differentiating between a bad header format and expired token). If the credentials are valid, but do not provide sufficient scope, a 403 is returned. 403 means that the authentication was successful, but that that client is not allowed to execute the request. If the credentials are valid, have sufficient scope, but the request itself is invalid, a 400 is returned. This text and the text it originally derived from are incorrect in their use of 400 to indicate an invalid authorization header. This section needs to be edited to reflect the three states: 401: Invalid authentication (both invalid_request and invalid_token) 403: Valid authentication, insufficient scope - since no discovery provided, including a new WWW-Authenticate doesn't help much, even with the scope parameter 400: Valid authentication, sufficient scope, invalid protected resource request Arguable, specifying anything other than the 401 response and its errors exceeds the scope of this document and steps over HTTP. I would recommend dropping all responses other than 401 since they are just how HTTP works and explicitly defining them give the impression that other HTTP status codes are not allowed. EHL
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
