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