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!

[vadimkantorov]

sigh :(

[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/

[vadimkantorov]

Got it. And does Sveltia also support this mode? This (admittedly cumbersome) mode can be a useful sometimes for multi-contributor websites (while waiting for proper no-backend mode)

[kyoshino]

It’s an OAuth (or GitHub) application setting, not something that CMS frontend has to support. See https://github.com/sveltia/sveltia-cms-auth

[vadimkantorov]

Oh, I see - this return url must be a backend-ful app? Could it be just an HTML static page? (e.g. hosted on the website's domain static hosting)

Meaning: could the redirect be handled by pure JavaScript code embedded in HTML / index.html?

[seanorama]

Any word on when this will land in GHES?

[imjasonh]

@hpsin Any update on CORS support?

Is there a separate issue/discussion I can subscribe to for that?

[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

[monarchwadia]

@hpsin I am building a desktop app. I want to allow the user to connect to Github and provide my app with read access.

My questions are:

1. My understanding is that I will have to ship the client_secret, thus making it a "public client secret"... is that a fair assessment? Is this Github's recommended practice, given that VSCode, Visual Studio, GH CLI, Github Mobile all do this?
2. What are the right steps for mitigating risk on my end?
3. And, also, how does Github mitigate risk for this use case on its end? What is the security model like?

[hpsin]

1. Yes, that's the case. We want to move away from that since it's a common thing people trip up on. This is on the public roadmap here: Single page app support for GitHub Apps [Preview] github/roadmap#1153 (native apps to come, but a similar outcome)
2. Ensure that you are not making assumptions on a backend that a token from "your app" (meaning from your client ID) is de facto trustable. (I.e. "This token came from XX App so it can call this API"). This is true regardless of whether you have a client secret or not because you cannot validate the legitimacy of a public client. Beyond that there's nothing you need to do. The client secret can only be used to manipulate a token someone has in possession - there's nothing it can do without a token.
3. As above :)

[monarchwadia]

Thank you @hpsin that makes sense. I appreciate the response!

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

[kyoshino]

@hpsin It’s been six months since GitHub missed its Q4 2025 goal to release PKCE support for SPA. Any news about this?

Our Sveltia CMS, the de facto successor to Netlify CMS mentioned in the OP, is becoming more popular. We estimate that it now has thousands of users worldwide.

Sveltia CMS has supported PAT authentication since July 2025, but the number of installations of our own OAuth client, Sveltia CMS Authenticator, continues to increase due to the lack of PKCE support.

We really hope the feature will be implemented soon.

[MoritzWeber0]

Is there any addition information on why #1153 was changed to paused?

[kyoshino]

It’s disappointing, but not surprising. GitHub has been going downhill for a while. I can’t imagine the company going bankrupt since it’s part of Microsoft, but frequent downtime, Copilot mishaps, and the neglect of Dependabot (which keeps spamming our inbox), npmjs.com (which has no dark mode) and so on all indicate that the platform is not being maintained as well as it should be.

[kyoshino]

If it’s a financial issue, they should be promoting GitHub Pro membership more aggressively. But they don’t — it’s a leadership issue.