Issue token to allow shifting JupyterHub API calls to frontend

[minrk]

Proposed change

Idea discussed with @yuvipanda. The gist is to move JupyterHub API calls to the frontend, so that a client library can control building and launching.

Right now, the sequence is:

1. binderhub builds image
2. binderhub creates jupyterhub user via API
3. binderhub 'issues' token (generates random string)
4. binderhub sends API request to hub to launch jupyter-server with the token

Proposed sequence changes at step 3 to use the JupyterHub API to issue a real short-lived token that can be used to launch the server.

For example:

# POST /api/users/:name/tokens
{
  "expires_in": 900, # 15 minutes - whatever spawn timeout should be
  "scopes": [
    "servers!server=username/", # start/stop the server
    "access:servers!server=username/", # access the server (not really used unless jupyterhub-singleuser is launched)
  ],

The build event stream would then end with this token, and the client library would take over, making the API requests to launch and await the server instead of BinderHub.

Issues to consider:

• limiting what image(s) can be spawned with the token
• enforcing quotas when BinderHub doesn't decide when to launch
• how does this interact with authenticated BinderHub?

Alternative options

Run the anonymous user-creating service somewhere else, so that launch is fully decoupled from BinderHub (or still inside BinderHub, but decoupled from build). This requires more thought, since there are major security implications, but ultimately BinderHub already is this - you can create any number of anonymous JupyterHub users by requesting builds. But BinderHub quotas apply limits, which may become tricky to enforce.

Who would use this feature?

binderhub-client javascript library could control building and spawning.

[yuvipanda]

yesssss i like this.

[yuvipanda]

Currently, it looks like if authentication is enabled, we simply skip the 'create user' step. We can continue to do that here, right?

[yuvipanda]

In general moving binderhub's scope to be narrower will be a useful direction to take in the long / medium run. This allows it to get out of the business of 'launching jupyterhub user servers'. That can be a client responsibility. And we can do this without changing the experience on mybinder.org easily.

me likey the scopey. Thanks, @minrk

[minrk]

Currently, it looks like if authentication is enabled, we simply skip the 'create user' step. We can continue to do that here, right?

I think so. And indeed, we could use the OAuth token issued to binderhub during oauth as the token (make sure the launch permissions are in oauth_client_allowed_scopes). In the auth case, I think this would remove any need for BinderHub to make API requests to the Hub aside from the standard oauth requests. That means the BinderHub service would need no permissions at all.

I think enforcing quotas and limiting images are going to be the tricky parts, since BinderHub is no longer involved in that step, and JupyterHub doesn't have that understanding. That logic would need to move to the BinderHubSpawner, I guess.