Return to Answer

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 application/json;charset=UTF-8.?.
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.

^{(Emphasis added)}
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 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".

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 application/json;charset=UTF-8.?.
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.

^{(Emphasis added)}
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 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".

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

Update: Apparently 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 application/json;charset=UTF-8.?.
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.

^{(Emphasis added)}
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 Stack Exchange OAuth2, explicit access-token response format does not adhere to RFC6749 standard and 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".

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 application/json;charset=UTF-8.?.
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.

^{(Emphasis added)}
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 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".

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

Update: Apparently 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 application/json;charset=UTF-8.?.
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.

^{(Emphasis added)}
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 is how it should be.

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

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

Update: Apparently 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 application/json;charset=UTF-8.?.
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.

^{(Emphasis added)}
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 Stack Exchange OAuth2, explicit access-token response format does not adhere to RFC6749 standard and 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".