-3

I'm getting the following response body and header from https://stackoverflow.com/oauth/access_token when attempting to exchange an oauth code for a token:

<DEBUG> [00:30:03] my-app - content-type: text/plain; charset=utf-8 <DEBUG> [00:30:03] my-app - response: access_token=<redacted>&expires=86400

I'm writing an oauth2 client not specific to stack exchange and I'm not sure how to handle this kind of response in a generic way, since it's neither JSON, nor does the content-type give me any useful indication on how to interpret the content without looking at the content itself.

Should the content type be x-www-form-urlencoded?

Improve this question
2
  • No. As already explained, x-www-form-urlencoded is 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. Commented Nov 1, 2018 at 21:37
  • Yes, I am aware of my own answer pointing out the new json endpoint in the doc. Thanks. Commented Nov 2, 2018 at 16:37

1 Answer 1

Reset to default
0

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

Improve this answer
3
  • sorry, what isn't clear about the question? is there skepticism about whether the API actually sends back the content-type and response as stated? Commented Nov 1, 2018 at 18:58
  • I don't understand why the stackexchange API would use this custom non-standard response format instead of a standard JSON object that most REST api libraries understand. Also inconsistent with most of the rest of the API which uses JSON. Commented Nov 1, 2018 at 19:14
  • @user84207, the question was not clear because (1) you were getting an access_token, which is the whole point, (2) the question shows confusion about the purpose and use of x-www-form-urlencoded, (3) you listed no actual practical problem. Contrast this to the linked bug report. Commented Nov 1, 2018 at 19:50

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.