[BUG] - Do not show oauth screen for users accessing the main jhub-apps service

[krassowski]

Describe the bug

In nebari (and often in JupyterHub in general) the auth sequence involves two or three OAuth providers:

• JupyterHub OAuth provider, which calls
• Keycloak OAuth provider, which (sometimes) calls
• External third-party OAuth provider (e.g. Google or GitHub).

In such setups the JupyterHub OAuth provider is meant to be transparent to the users unless user grants additional permissions to third-party services. Typically JupyterHub OAuth checks the user identity when spawning servers, and verifies that user wants to share their identity (or specific permissions) with services.

Jhub-apps is a service which requires users to confirm that they agree to share the JupyterHub OAuth identity with the service. Currently, a confusing screen is shown to users when they first log-in into JupyterHub, after they already authenticated with Keycloak:

It is confusing because users do not know what "japps" (sic!) service is, nor what the default scope description ("Identify the owner of the requesting entity") mean, since a very technical language is used.

This screen is not always necessary, user servers are by default confirmed without user action, and services "blessed" by administrator of the JupyterHub are also handled transparently. This is configured by setting oauth_no_confirm in the service configuration.

Expected behavior

Since jhub-apps is tightly integrated with nebari it makes sense to exempt it from user making the explicit confirmation that they do want to share their identity with jhub-apps.

If we do want to keep this screen however, we may want to customize it to better describes which actions the service will perform on behalf of the user (like creating named servers, sharing servers, etc) as access to this actions is currently permitted via a separate token rather than through oauth scopes.

We previously had oauth_no_confirm set to True on some services used when jhub-apps is enabled. This got removed during JupyterHub 5 upgrade (#2427) due to JupyterHub now requiring additional URL configuration for it (jupyterhub/jupyterhub#4801). The removal was based on a conversation in which these services were described as applications that do not oauth with JupyterHub, but uses keycloak directly. This is correct, these services:

nebari/src/_nebari/stages/kubernetes_services/template/modules/kubernetes/services/jupyterhub/files/jupyterhub/02-spawner.py

Lines 77 to 84 in 4f8fc54

	c.JupyterHub.services.extend(
	[
	service_for_jhub_apps(name="Argo", url="/argo"),
	service_for_jhub_apps(name="Users", url="/auth/admin/nebari/console/"),
	service_for_jhub_apps(name="Environments", url="/conda-store"),
	service_for_jhub_apps(name="Monitoring", url="/monitoring"),
	]
	)

do not use JupyterHub oauth but they use Keycloak directly.

However, jhub-apps itself as of today:

• does not have any references to keycloak (and is designed to work in nebari-agnostic environments)
• uses JupyterHub as an oauth provider, see jhub_apps/service/security.py

The code change would need to be done in:

nebari/src/_nebari/stages/kubernetes_services/template/modules/kubernetes/services/jupyterhub/files/jupyterhub/02-spawner.py

Line 87 in 4f8fc54

c = install_jhub_apps(c, spawner_to_subclass=KubeSpawner)

By passing a new oauth_no_confirm argument down to where the main jhub-app service is appended to c.JupyterHub.services in jhub-apps.

We should probably also rethink the name of the service, it is currently set to japps (here) which does not correspond to jhub-apps used in the documentation.

OS and architecture in which you are running Nebari

Irrelevant

How to Reproduce the problem?

1. Deploy nebari with jhub_apps.enabled: false
2. Create a new test user in keycloak
3. Login to nebari as that test user
4. See that everything is fine, logout
5. Re-deploy nebari with jhub_apps.enabled: true
6. Login to nebari as the test user again
7. See the OAuth screen prompting for confirmation

Command output

No response

Versions and dependencies used.

No response

Compute environment

None

Integrations

No response

Anything else?

No response

[krassowski]

What do you think @aktech?

[aktech]

This is a good idea! thanks for the detailed issue.

[Adam-D-Lewis]

I'm going through triaging issues today and saw this one. Looks like a nice improvement. I agree that that "japps" would be better as "jhub-apps".