How to ensure all token in JupyterHub are short lived

JupyterHub Zero to JupyterHub on Kubernetes
, , , ,
1

Hi

I am trying to find a way to set short lived tokens instead of Never expire when Single user server is started by JupyterHub

I see despite setting oauth_token_expirty with some value I see an API tome Server at /user/username everytime getting created which never expires.

I understand this tokens are revoked when the servers is stopped and is closely associated with server lifecycle

However I want this to be still expiring and I am ok for my users to stop and start the server after like a day or two

This is causing security vulnerabilities as the token should expire after a certain time.

Any suggestions would be really appreciated,

I have gone through the PR ( Controls for JupyterHub API tokens · Issue #4028 · jupyterhub/jupyterhub · GitHub ) but none of those options works as they do not enforce short lived tokens

2

I think your best solution is to configure the idle culler to limit the lifetime of a singleuser server

The default server scope is already very limited

1 Like
3

Hi @manics

Thank you for your response, I already have a culler logic setup also ensuring the API token is revoked when the server is stopped. But the main concern is that security team would not agree setting up any kind of token with expiry as Never

I need a way to set API token Server at /user/{username} to have an expiry instead of never during the server is active. I completely understand there may be consequences of setting short lived token and I am ok to have them revoked,

I will set the long expiry maybe 1 week 2 week. But the “Never” expire tokens does not meet security standards.

I think there is no way to which comes out of box at the moment,

I am open to apply customizations as well for this may be updating the PG database for these tokens.

4

Have a look at this closed issue: Controls for JupyterHub API tokens · Issue #4028 · jupyterhub/jupyterhub · GitHub

There is a discussion there about how to redefine the user role so they can’t mint those API tokens. That may be more aggressive than you want to be, but it will probably satisfy your security team’s requirements.

5

Hi @rcthomas @minrk

Thank you for your response @rcthomas

I’ve reviewed all four options you mentioned and have already implemented role-based restrictions to limit API token creation.

However, my concern is with the API token that gets automatically generated when a single-user server is spawned.

As soon as the spawn process begins, a “never expires” token with the note “Server at /user/username” is created. From what I understand, this token is tied to the server lifecycle, and there’s already an enhancement where it gets revoked when the server (and user) is culled — which works as expected.

That said, the fact that this token has no expiration remains a concern for our security team.

I’ve already configured oauth_token_expires to set a short expiry for OAuth access tokens, which I believe takes precedence in some scenarios — but it does not appear to apply to the server-generated API token. If there’s any way to enforce or configure an expiry for that token,

We do not require long-running servers, so introducing or enforcing an expiration would not be an issue. In fact, I could even align the token expiry with the maximum server lifetime defined in our culling logic --max-age