Subject: [OAUTH-WG] Returning 405 Method Not Allowed at token endpoint

From: André DeMarre <[email-masked]>
Date: Fri, 22 Mar 2013 15:08:02 -0700

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