So we want to manage authentication by:
Explicitly listing the type of connection we want for this hub, via
auth0.connection. Currently common ones are
google-oauth2for Google &
githubfor GitHub. Users of the hub will use this method to log in to the hub.
You can set the auth0 connector for a hub with:
auth0: connection: google-oauth2
Theoretically, every provider in this list is supported. However, we’ve currently only tested this with Google (
google-oauth2) and GitHub (
Explicitly list admin users for a given hub. These admin users will be the only ones allowed to log in to begin with. They can use the JupyterHub admin interface (available from their hub control panel) to explicitly allow more users into the hub. This way, we don’t need to be involved in explicitly allowing users into hubs.
In the admin interface, admin users can add users via a username appropriate for the auth connector used. For GitHub, it’s the username. For Google Auth, it’s the email address.
You can set the admin interfaces for a hub like this:
config: jupyterhub: auth: # will be renamed allowedlist in future JupyterHub whitelist: users: # WARNING: THESE USER LISTS MUST MATCH (for now) - email@example.com - firstname.lastname@example.org admin: users: # WARNING: THESE USER LISTS MUST MATCH (for now) - email@example.com - firstname.lastname@example.org
Switching authentication for a pre-existing hub will simply create new usernames. Any pre-existing users will no longer be able to access their accounts (although administrators will be able to do so). If you have pre-existing users and want to switch the hub authentication, rename the users to the new auth pattern (e.g. convert github handles to emails).