The OAuth 2 core spec says the client MUST use POST at the token endpoint (Section 3.2), but it doesn't specify the error response if a different method is used. While describing the error responses for the token endpoint in section 5.2, only 400 and 401 status codes are used.
I believe the proper HTTP response should be a "405 Method Not Allowed" along with an "Allow: POST" header. That is what Google's implementation does, and their response body is HTML and not an OAuth error response at all (https://accounts.google.com/o/oauth2/token). Does using 405 conflict with the OAuth 2 spec? Possible interpretations that reconcile the conflict: 1) If a request at the token endpoint doesn't use POST, it isn't technically an access token request, and the server response isn't bound to the OAuth spec at all. (Google uses an HTML error page.) 2) Section 5.2 paragraph 1 appears to be non-normative, where it mentions code 400. The only HTTP error response declared normatively by the spec is 401 regarding failed client authentication. This leaves the server open to implement other status codes in compliance with the HTTP spec along with with OAuth error responses. For example, using 405 Method Not Allowed along with a {"error":"invalid_request"} error response. This is pedantic, but can a compliant authorization server use 405 in response to unsupported method requests at the token endpoint? It doesn't matter from an interoperability standpoint, but I'm noticing this particular error case being handled differently between auth server implementations. Regards, Andre DeMarre _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
