- Notifications
You must be signed in to change notification settings - Fork2.1k
enable PKCE for internal OAuth#4936
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:main
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
Conversation
currently optional
minrk commentedFeb 7, 2025
supporting PKCE also opens the door tooauth without client secret, which would enable e.g. javascript applications to login with jupyterhub without a server-side component. This PR doesn't yet implement that, but it should be a pretty small change after this, Ithink with no db change (e.g. |
minrk commentedOct 2, 2025
I'd like to get 5.4 out, then come back to this and require Python 3.10 for jupyterhub 6 |
Uh oh!
There was an error while loading.Please reload this page.
seejupyterhub/oauthenticator#765 for implementing PKCE in OAuthenticator. This does the same in jupyterhub's oauth clients and adds what is needed for the provider side (oauthlib implements the verification, we only need to implement the db persistence of the challenge)
PKCE is currently optional for backward-compatibility
Since this adds db columns, this means a major version bump according to#3982
TODO:
It would be nice for PKCE to happen by default, but we need to make sure that existing code will either transparently send both the challenge and the verifier or neither, because e.g. sending the challenge but not the verifier will cause every oauth to fail. Sending neither is still okay as long as
require_pkceis not enabled, which will be opt-in.