Support PKCE flow for OAuth apps

[jimafisk]

GitHub let's you authorize apps using OAuth but the supported grants require a server, making it difficult for clientside apps.

This requires Jamstack git-backed CMS projects like NetlifyCMS manage an intermediary server separately: https://www.netlifycms.org/docs/github-backend/ (same with TinaCMS and my project Plenti).

The Implicit Grant type was not allowed because of security issues, but Proof Key for Code Exchange (PKCE) should allow clientside apps to operate securely.

GitLab already implements this in their OAuth 2.0 identity provider API: https://docs.gitlab.com/ee/api/oauth2.html#authorization-code-with-proof-key-for-code-exchange-pkce

Thank you!

[jimafisk]

Another related discussion: https://github.com/orgs/community/discussions/40077

And documentation issue: github/docs#22270

[madhurigopal]

I think we need to Authorize using a local instance of a DB with Cloud connectors something that Langfuse folks do! Do check it out.

[writeonlycode]

I would love see support for PKCE as well. It would make a huge difference for JAMStack websites.

[gopi-suvanam]

+1

PKCE is important for decoupling services and UI..

[hickford]

PR to clarify that PKCE is not supported github/docs#24965

[Tachi107]

GitHub now supports the Device Authorization Grant, which does not require a server.

This is not an excuse to not support PKCE, since its usage is recommended (and sometimes required) starting with the upcoming OAuth 2.1 standard.

[gopi-suvanam]

In device authorizaiton grant, why is there no verification_url_complete ?

[Evidlo]

GitHub now supports the Device Authorization Grant, which does not require a server.

I think CORS settings on https://github.com/login/device/code prevent this. At least I'm getting CORS errors when I try.

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://github.com/login/device/code. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 200.

https://github.com/octokit/authentication-strategies.js/?tab=readme-ov-file#device-authentication
https://stackoverflow.com/questions/42150075/cors-issue-on-github-oauth

So there is still no way to do client-side auth for GitHub apps!

[matheuscscp]

Is PKCE missing only for OAuth Apps or is it missing for GitHub Apps as well? The docs here don't mention "pkce" nor "challenge": https://docs.github.com/en/apps/creating-github-apps/writing-code-for-a-github-app/building-a-login-with-github-button-with-a-github-app

[Kamil777]

[Tachi107]

Is PKCE missing only for OAuth Apps or is it missing for GitHub Apps as well?

As far as I know, it's also missing from GitHub Apps.

[DDevine]

I really would prefer if Github had PKCE. It greatly simplifies things for static web applications.

[hpsin]

Hey all,
Happy to say we have added support on GitHub.com for PKCE. We'll bring it to GHES in a bit, once we build some tooling for the compat problem

https://github.blog/changelog/2025-07-14-pkce-support-for-oauth-and-github-app-authentication/

[hpsin]

We still have to add support for CORS on the token endpoint unfortunately. We are working on it though.

For the client secret, yes, our implementation always requires the client secret as we don't yet distinguish between public clients and confidential clients. So at this time, native apps and SPA type apps need to include their client secret in the redemption. I don't have an estimate for when we can remove this requirement unfortunately.

[kyoshino]

We cannot embed a client secret in our SPA or ask end-users to enter their client secret. So we have to wait until the requirement is removed. We could rather prompt users to enter their personal access token directly, as discussed here:

• Is it possible for Netlify CMS to simply authenticate directly with GitHub? decaporg/decap-cms#663

[Evidlo]

So just to confirm, we still cannot authenticate client-side webapps without a backend with Github?

It's currently possible to generate a link to the personal access token page which could be copy-pasted into the app to give it access to the user's repositories/gists/etc, but this is not very ergonomic.

[hpsin]

Ah, I'm sorry to hear that. Correct, you cannot yet auth a SPA as we don't have CORS for the token endpoint yet. We'd really love to not have folks create PATs for this, so I'll update when I have more details about the CORS options here.

[kyoshino]

Once the CORS issue is resolved, I would try the device flow as discussed earlier, which doesn’t require the client_secret param.

Our situation is a bit complicated. Sveltia CMS is not SaaS but (semi) self-hosted. We serve the SPA via UNPKG, and users have their own instances. Since the redirect_uri varies by user, each user must install an OAuth client on Cloudflare Workers and register it with GitHub, which is cumbersome. From a UX standpoint, prompting for a PAT is much simpler.

Anyway, it’s great to hear that GitHub is working on this. Keep it going!

[gopi-suvanam]

Is it safe to keep client secret in the front end.. it won't be a "secret" any more

…

On Tue, 15 Jul, 2025, 8:10 pm Hirsch Singhal, ***@***.***> wrote: We still have to add support for CORS on the token endpoint unfortunately. We are working on it though. For the client secret, yes, our implementation always requires the client secret as we don't yet distinguish between public clients and confidential clients. So at this time, native apps and SPA type apps need to include their client secret in the redemption. I don't have an estimate for when we can remove this requirement unfortunately. — Reply to this email directly, view it on GitHub <#15752 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQNBZSV5HPH2K3CNTDECYBL3IUHGBAVCNFSM6AAAAABTOFAC3WVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGNZWGU3TGNQ> . You are receiving this because you commented.Message ID: ***@***.***>

[hpsin]

Yes, we don't have a "public client" concept yet, so we treat all clients the same and all of them require access to the client secret. You cannot keep a secret "secret" within a public client, but you do have to embed it there anyhow. This is how e.g. VS Code, Visual Studio, GH CLI, and GitHub Mobile all work.

You can read a bit more about that here: https://docs.github.com/en/enterprise-cloud@latest/apps/creating-github-apps/about-creating-github-apps/best-practices-for-creating-a-github-app#client-secrets

[gopi-suvanam]

We are also Asking user to enter the token. Will wait for fully client side authentication to be enabled

…

On Tue, 15 Jul, 2025, 10:52 pm Kohei Yoshino, ***@***.***> wrote: We cannot embed a client secret in our SPA or ask end-users to enter their client secret. So we have to wait until the requirement is removed. We could rather prompt users to enter their personal access token directly, as discussed here: - decaporg/decap-cms#663 <decaporg/decap-cms#663> — Reply to this email directly, view it on GitHub <#15752 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQNBZSVDSIGGNJVDL7D4WWL3IU2DPAVCNFSM6AAAAABTOFAC3WVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGNZWG42DGNQ> . You are receiving this because you commented.Message ID: ***@***.***>

[mig5]

I am using Vouch which was already sending PKCE code_challenge_method S256 to Github with a correct 43 char length of code_challenge, yet I got the email saying my Github OAuth app was using PKCE incorrectly..

I set up a new Github OAuth app and it Just Worked despite me not changing anything other than the client ID and client secret in my Vouch config. (I also set the redirect_uri which is optional but which Github 'strongly recommends' according to the docs

However, after it working the first time, I now get a 400 error with the Github side returning: oauth2: \"bad_verification_code\" \"The code passed is incorrect or expired.\" \"https://docs.github.com/apps/managing-oauth-apps/troubleshooting-oauth-app-access-token-request-errors/#bad-verification-code\""}

This is weird, it was working ok on the older OAuth apps...? So I'm doubly confused why the old apps were apparently 'incorrect', and why the new app worked only once, despite me not having changed other parameters.

I'm pretty sure Vouch does everything correctly, it's a solid OIDC sidecar for Nginx.

I've filed an upstream issue at vouch/vouch-proxy#600 about it though.