django-oauth-toolkit
django-oauth-toolkit copied to clipboard
jazzband
Use of Content-Type "application/x-www-form-urlencoded" not enforced
The RFC 6749 seems to suggest that the Content-Type application/x-www-form-urlencoded should always be used in POST requests.
In a more specific way, the RFC6750 states that:
When sending the access token in the HTTP request entity-body, the client adds the access token to the request-body using the "access_token" parameter. The client MUST NOT use this method unless all of the following conditions are met:
o The HTTP request entity-header includes the "Content-Type" header field set to "application/x-www-form-urlencoded". ...
After a quick look around, many other projects seem to enforce this content type with the exception of auth0.
At the moment, django-oauth-toolkit allows other content types and it has even a specific class for parsing JSON requests which was introduced in PR 234.
It would probably be a good idea to enforce the use of application/x-www-form-urlencoded to align with the RFCs but as it requires changes that could break many existing projects relying on DOT, it would be worth discussing the issue here first.
Bump on this issue. If I'm understanding this would it also apply to the POST /oauth/token/ endpoint? We have external users running into this issue. We're not entirely sure how to deal with it. To my understanding this is what the 415 response code is for.
If a user sends an application/json request they end up getting a 400 saying {"error": "unsupported_grant_type"}. It appears the view can't find any data in the request as non of the parameters are found.
I think a 415 with a more appropriate message would make more sense.
Bump on the issue, I guess.
If a user sends an application/json request they end up getting a 400 saying {"error": "unsupported_grant_type"} which is confusing, since they are setting the grant type.
feel free to submit a PR that doesn't break things for existing users (e.g. selectable via a setting).
It is common to send the access token as Authorization header Bearer token so I don't know how many users are sending the access_token in the body instead.
