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.
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.
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
We could attach a lifetime to that token, but it does have a finite lifetime in that it gets revoked when the server is stopped. So if your servers have a maximum lifetime, that’s the actual max lifetime of that token. And restarting the server revokes that and re-issues that token.
If server max age were something that was part of JupyterHub internally, we would set it automatically.
We can add an option to limit these so you don’t have to trust the revoke-on-stop mechanism, which could result in servers not functioning properly if they run longer than the expiration, so it would be up to the deployment to make sure the expiration makes sense, as refresh tokens are not yet supported. With refresh tokens, these could easily have a much shorter lifetime, but that becomes tricky because these are typically retrieved from environment variables, which can’t be changed for running processes.