The question is either not completely clear or a duplicate. You may need to post an MCVE.
According to the OAuth 2.0 Authorization spec (RFC 6749), section 5.1:
The parameters are included in the entity-body of the HTTP response
using the "application/json" media type as defined by [RFC4627]
So, apparently the
content-type should be
That would seem to make sense.
Also note that officially:
Restrictions on usage :
This type (x-www-form-urlencoded) is only intended to be used to describe HTML form submission payloads.
x-www-form-urlencoded is only for submissions to the server, not responses to the client.
Your app code (and the API) appears to be working properly, you are getting an
access_token in the body.
And yes, the body is
text/plain (transmitted via SSL). That might be permissible. See Stack Exchange OAuth2, explicit access-token response format does not adhere to RFC6749 standard and see RFC 6750.
The purpose of
x-www-form-urlencoded is to package data in an unambiguous way that removes conflicts with the HTTP protocols (reserved characters, etc.). It is separate but: related to, more compact than, more strict than, and more specialized than HTML -- which is what the server uses to send back the response.
Since a server's response to a form POST is expected to be valid HTML, there is no need for form or URL encoding.
You can think of x-www-form-urlencoded as a kind of "micro format".
x-www-form-urlencodedis not for server responses. You know what to expect because (A) The docs tell you exactly and (B), the page is in direct response to your
POST. ... Also note that other general clients have no troulbe handling the Stack exchange API, even though it is non-conforming. (Nevertheless, the linked bug should be resolved.) Update: Turns out the FR/Bug was silently resolved last year. See the duplicate question.