The question is not completely clear. You may need to post an [MCVE][1].

**Update:** Apparently according to the [OAuth 2.0 Authorization spec (RFC 6749), section 5.1][2]:

> 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 `application/json;charset=UTF-8`.?.  
That would seem to make sense.

Also note that [officially][3]:

> Restrictions on usage :  
This type (x-www-form-urlencoded) is only intended to be used to describe HTML **form submission** payloads.

<sup>(Emphasis added)</sup>  
**That is, `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 *https://stackapps.com/questions/4132/stack-exchange-oauth2-explicit-access-token-response-format-does-not-adhere-to* and [RFC 6750][4].

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".


  [1]: https://stackoverflow.com/help/mcve
  [2]: https://tools.ietf.org/html/rfc6749#section-5.1
  [3]: https://www.iana.org/assignments/media-types/application/x-www-form-urlencoded
  [4]: https://tools.ietf.org/html/rfc6750