OAuth web flow endpoints don't support CORS

[stuartpb]

All of the API v3 endpoints on api.github.com support CORS (https://developer.github.com/v3/#cross-origin-resource-sharing): however, the github.com endpoints involved in creating an OAuth2 access token via the Web Flow, specifically https://github.com/login/oauth/access_token, don't support the OPTIONS method or CORS headers necessary to POST to it and get the access_token back.

This is a bug. Denying cross-origin access here doesn't help security, as it is most easily worked around by doing the POST requests through a potentially-insecure third-party open reverse proxy (as implemented using https://cors-anywhere.herokuapp.com/https://github.com/login/oauth/access_token on http://stuartpb.github.io/gistachio/demo.html).

[stuartpb]

On 1/8/2015 12:56 AM, Ivan Žužak wrote:

Hi Stuart,

Thanks for the feedback. The GitHub API's OAuth implementation doesn't support the implicit OAuth flow currently, which would allow you to complete the OAuth flow from a browser:

https://tools.ietf.org/html/rfc6749#section-4.2

Improving our implementation so that this is supported is already on our wishlist, but I can't say if/when it might happen. For now, you should use a server-side component to complete the flow (your own server-side component, not a potentially-insecure third-party component you can't really trust).

Allowing CORS for the endpoint you mentioned would mean that you could complete this step of the Web flow from a browser:

https://developer.github.com/v3/oauth/#github-redirects-back-to-your-site

And this would mean that you're hard-coding your client_id and client_secret into a webpage (or JS file loaded into that webpage) for everyone to see. This would indeed cause security concerns since the client_secret should be kept secret. If someone got hold of your client_id and client_secret, they could impersonate you application, and for example -- wipe all the tokens for that application:

https://developer.github.com/v3/oauth_authorizations/#revoke-all-authorizations-for-an-application

Let me know if you have any other feedback or questions.

Cheers,
Ivan

[stuartpb]

Ivan has a point, and implicit OAuth really would be the correct solution here. The app I'm exposing the client_secret in is a demo, so I don't really care if it can be impersonated or wiped, but in general sending client_secret to the browser is wrong, and I certainly wouldn't do it for any meaningful app.

(I'd been considering it for a browser extension, but I didn't know / hadn't considered that the client_secret can be used to invalidate all tokens, so now I'm definitely going to set up a lightweight token generator server to obscure the secret.)

However, I'm not really a fan of GitHub's "security through not fixing bugs that are situationally mildly discouraging" rationale (as seen here and in #316).

[ericsoco]

I wasted the better part of a day on this dead end, trying to get the implicit OAuth2 flow to work w/ GitHub's API. I didn't notice the fine print at the top of the docs.

It seems like way too much of a hurdle to have to spin up a server just to connect an application to GitHub. But for future reference, here's a simple one, tailor-made for this problem:
https://github.com/prose/gatekeeper

[wonderbeyond]

I want to make a pure-javascript in-browser gist client, So CORS support is necessary!

[axetroy]

@wonderbeyond
That's great! I am doing something like you.

a serveless website, All data from Github api, so back the point.

CORS support is necessary!

[moodysalem]

I want to build a password database hosted in a private GitHub repository and I can't build trust because the access code has to be sent to an endpoint I host that trades a access code for a token
https://github.com/pdelta/pdelta.github.io/issues/1

[amaralDaniel]

Any updates on this?

[mrahman1122]

Have there been any updates on this issue??

[chulman444]

The request is successful in the network tab of the chrome dev tool. I can see my access_token in it, however I can't retrieve the access_token in my script because of the error ... blocked by CORS policy: No 'Access-Control-Allow-Origin' header.

Sending the access_token request with axios.post(url_with_oauth_params).

So, is this resolved, or was it like this before?; seeing successful request-response in the network tab, but unable to retrieve it in the script?