Non-standard response for OAuth Device Grant request

Hey :wave: I was recently looking at cli’s oauth library as a potential pre-existing solution and noticed that, unlike other providers I was aware of, the library consumed application/x-www-form-urlencoded responses. This was a conflict against other services that returned application/json responses.

My initial thought was that the oauth library must be setting a Accept header, but on further inspection that did not appear to be the case. I went further and did some work to support arbitrary OAuth servers to verify that the form response wasn’t something that would appear with other providers using the library. Sure enough, those providers would still respond with application/json responses.

I next referred to the relevant GitHub documentation page on the matter, which states that the route responds with application/json as other providers do. There was no mention of responses of application/x-www-form-urlencoded. I finally consulted RFC 8628, which states “and includes them in the HTTP response body using the “application/json” format [RFC8259] with a 200 (OK) status code”.

By this point, I’ve decided to roll my own library for OAuth (and Device Grants) - and did some further testing within the codebase. The GitHub OAuth server does indeed act unaccordingly with the specification, returning application/x-www-form-urlencoded for standard responses. Though worthwhile of note, with an Accept header set to application/json I was able to get a standard response.

This is non-standard behaviour though, and should work in the reverse if the application/x-www-form-urlencoded responses are actually desired.


tl;dr: GitHub’s implementation of the OAuth Device Grant doesn’t produce responses of the media type as specified by the RFC (application/json). This is in contradiction to other providers, GitHub’s own documentation, and the RFC.

1 Like