Problem Statement
As a JupyterHub administrator, I work with external identity providers. Most of these in practice follow the OIDC standard, which adds some specific choices and standards which the underlying OAuth leaves unspecified, leading to more verbose configuration with opportunity for error. It would be simpler to configure authentication for JupyterHub with many providers, including Auth0, KeyCloak, Google, and others if we had first-class support for OIDC in addition to generic OAuth.
Proposed Solution
Support easier configuration with OIDC providers rather than requiring full OAuth configuration, much of which can be automatic when it is know that the OAuth provider follows OIDC.
Proposed Implementation
Add an OIDCProvider to OAuthenticator and support .well-known/openid-configuration in JupyterHub. Not in scope (for now) is adding scopes to JWTs for being able to validate a token without checking with JupyterHub.
How will this fit in the ecosystem?
Many JupyterHub deployments today use an OIDC provider with OAuthenticator. These deployments would be simplified by adding OIDCAuthenticator to OAuthenticator, requiring less configuration.
Endorsements
- @minrk who has been working a lot with OIDC providers and re-writing the same several lines of oauth config over and over again, where all I should need is
.well-known/openid-config
Problem Statement
As a JupyterHub administrator, I work with external identity providers. Most of these in practice follow the OIDC standard, which adds some specific choices and standards which the underlying OAuth leaves unspecified, leading to more verbose configuration with opportunity for error. It would be simpler to configure authentication for JupyterHub with many providers, including Auth0, KeyCloak, Google, and others if we had first-class support for OIDC in addition to generic OAuth.
Proposed Solution
Support easier configuration with OIDC providers rather than requiring full OAuth configuration, much of which can be automatic when it is know that the OAuth provider follows OIDC.
Proposed Implementation
Add an OIDCProvider to OAuthenticator and support .well-known/openid-configuration in JupyterHub. Not in scope (for now) is adding scopes to JWTs for being able to validate a token without checking with JupyterHub.
How will this fit in the ecosystem?
Many JupyterHub deployments today use an OIDC provider with OAuthenticator. These deployments would be simplified by adding OIDCAuthenticator to OAuthenticator, requiring less configuration.
Endorsements
.well-known/openid-config