Disable capability for users to create API tokens that never expire or hide Token tab

aspergillusOryzae20 · June 3, 2024, 7:56am

Looks like this was requested here:

Controls for JupyterHub API tokens

opened 09:46PM - 02 Sep 22 UTC

enhancement

JupyterHub has a [REST API](https://jupyterhub.readthedocs.io/en/stable/referenc…e/rest.html) that can be accessed using an API token. The API token can be created at in the Hub UI at `/hub/token` or through a [POST](https://jupyterhub.readthedocs.io/en/stable/reference/rest-api.html#/default/post_users__name__tokens) to the REST API itself. In the Hub UI a user can create a token with expiration of 1 day, 1 week, 1 month, or never. The API allows a user to set an arbitrary value for expiration. A user's tokens can be revoked by the user or by a user with the ability to revoke their tokens (e.g. an admin). I was wondering what controls JupyterHub admins have or could have to mitigate risk from lost or stolen JupyterHub REST API tokens. I'm opening this issue to capture discussion about potential controls to implement in JupyterHub, or that may already be available. Some of this has been scoped out with @minrk. In terms of remediation, if a user's token is known to be compromised, their accounts are possibly already locked and they may not have a way to revoke their own tokens. If an admin is informed that a user's token is compromised, they can delete the user from their Hub, use `python -m jupyterhub.dbutil shell` to remove the token, or make an API call to revoke the user's token. It may be a good idea to add to the Hub UI some way for users who can revoke other users' tokens a way to do that. This could be done by updating the URL scheme so such a user (e.g. an admin) can see another user's `/hub/token` page to do the revocation. In terms of more preemptive mitigations, might there be ways for admins to: 1. Disable generation of these general-purpose tokens altogether? 2. Enable generation of only more restrictively scoped tokens (a more restricted user role)? 3. Enforce a maximum lifetime for these general-purpose tokens, necessitating a re-auth? 4. Only allow token access from specified IP ranges? Option 1 works already through JupyterHub RBAC by replacing the default `user` role with one that cannot create API tokens. Thanks to Min for enumerating all the scopes here: ``` c.JupyterHub.load_roles = [ { "name": "user", "scopes": [ # read the user model "read:users!user", # manage the user's servers "servers!user", # access the user's servers "access:servers!user", # update activity (required for server activity) "users:activity!user", # keep read-only access to tokens # can't add or revoke tokens! "read:tokens!user", ] } ] ``` With this redefined `user` role, attempts to create a token fail with 403 Forbidden. Other tokens that are needed to operate notebooks and services still work just fine. This solution seems like a good one for folks who need to require their users to re-authenticate periodically to interact with Jupyter/JupyterHub. This may be worth including as documentation via example, and referencing that example from JupyterHub's RBAC and security docs? Option 2 is a little bit different from the above which just shuts off the ability to generate tokens. There might be some argument that users could have the ability to generate more restricted tokens and that's somehow OK. Are there use cases where that makes sense, and what kind of interface would be needed to manage all the different things you could pick and choose? Option 3 is something that is not possible now technically (this has been discussed previously in #1772 as well). It is something Min says he would like to be able to address as part of a better singleuser experience. I went into this favoring Option 4 personally, just allowing users to use tokens from specified IP ranges, but Min pointed out that mileage may vary due to issues with reverse proxying. If one were to try this it may just be best to do it at the edge or where SSL is terminated. Do folks have other thoughts, opinions, or other options?

Topic		Replies	Views
How to ensure all token in JupyterHub are short lived Zero to JupyterHub on Kubernetes community , jupyterlab , jupyterhub , how-to , help-wanted	5	71	August 19, 2025
Create New Token For User:- 403 Forbidden Zero to JupyterHub on Kubernetes help-wanted	4	71	September 30, 2024
Jupyterhub Custom API Token Auth JupyterHub jupyterhub , how-to , help-wanted	5	5522	January 14, 2022
Generate auth token using cli/api JupyterHub jupyterhub , how-to , help-wanted	1	312	April 17, 2024
Problems with token authentication -generated using REST API Zero to JupyterHub on Kubernetes	5	656	November 24, 2022

Disable capability for users to create API tokens that never expire or hide Token tab

Related topics