Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vdk-jupyter: impelement manual oauth2 login workflow #2591

Merged
merged 5 commits into from
Aug 24, 2023

Conversation

antoniivanov
Copy link
Collaborator

When jupyter notebook is deployed in a Multi-Notebook server instance (like jupyterhub) each user instance has a distinct URL. This means we don’t have a stable redirect URL to register with your OAuth2 provider.

User Scenario

  1. Every time a user starts a new notebook server, it gets a unique URL to their notebook
  2. OAuth2 Challenge: Since the redirect URL is dynamic based on the instance, we can’t pre-register a fixed callback URL with the OAuth provider.

Given this setup there are a couple of solution
A) The authorization provider could allow dynamic URLs (not very likely as it's not very secure)

B) The Notebook parent server could provide stable proxy to the underlyng notebook (so we can use http://jupyterhub/notebook?user=xxx and parent server would proxy this call to the user's notebook server). This way only the query paramter is dynamic which is often ok with authorization providers. The registered notebook url woudl be http://jupyterhub/notebook

C) If none of the above works , this solution is proposed where we can use Manual Login where user would need to copy one URL into the application.

Here is a short gif showing the process:

@antoniivanov
Copy link
Collaborator Author

Note : this is a stacked PR (https://benjamincongdon.me/blog/2022/07/17/In-Praise-of-Stacked-PRs/) . So will be merged after PR #2590 is merged

@antoniivanov antoniivanov force-pushed the person/aivanov/jupyter-ui branch from ef5f905 to edffe05 Compare August 21, 2023 12:36
@duyguHsnHsn
Copy link
Collaborator

The design seems a little bit off to me. Maybe changing the style of the listed items would make it look better and maybe the first button should be blue as the other "Ok" and "Continue" buttons from the Jupyter UI.

@antoniivanov antoniivanov force-pushed the person/aivanov/jupyter branch from d3f7fa3 to be12c5f Compare August 23, 2023 07:02
@antoniivanov antoniivanov force-pushed the person/aivanov/jupyter-ui branch from edffe05 to 5d994db Compare August 23, 2023 07:02
antoniivanov and others added 4 commits August 23, 2023 10:54
This is adding the server part of Oauth2 authentication process.

It adds 1 more APIs: `/login`

When called it without "code" query paramter, it will start the
authentication proces as per OAuth2 standard .
We are using only native app workflow with PKCE (RFC 7636) because we
cannot really secure the server side so we cannot reliably use client
secret.
When called with "code" query paramter it will finish the process and
exchange the code for access token (and refresh token) and safe it in
VDK storage.

This change add integration with jupyter configuration. This way the
extension can be configured more natively using jupyter configuration
mechanism.

In future change we can add integration between VDK configuration
mechanims and jupyter so that properties set in VDK can be recognized in
Jupyter and vice-versa but that's more advanced use-case
@antoniivanov antoniivanov force-pushed the person/aivanov/jupyter branch from d8dc793 to 4a393b8 Compare August 23, 2023 07:54
When jupyter notebook is deployed in a Multi-Notebook server instance
(like jupyterhub) each user instance has a distinct URL. This means we
don’t have a stable redirect URL to register with your OAuth2 provider.

User Scenario
1. Every time a user starts a new notebook server, it gets a unique URL
to their notebook
2. OAuth2 Challenge: Since the redirect URL is dynamic based on the
instance, we can’t pre-register a fixed callback URL with the OAuth
provider.

Given this setup there are a couple of solution
A) The authorization provider could allow dynamic URLs (not very likely
as it's not very secure)

B) The Notebook parent server could provide stable proxy to the
underlyng notebook (so we can use `http://jupyterhub/notebook?user=xxx`
and parent server would proxy this call to the user's notebook server).
This way only the query paramter is dynamic which is often ok with
authorization providers. The registered notebook url woudl be
`http://jupyterhub/notebook`

C) If none of the above works , this solution is proposed where we can
use Manual Login where user would need to copy one URL into the
application.

Here is a short gif showing the process:

<img
src="https://github.com/vmware/versatile-data-kit/assets/2536458/3831f5f6-c01e-411f-87fd-3d0945425e2e"></img>
@antoniivanov antoniivanov force-pushed the person/aivanov/jupyter-ui branch from 5d994db to dc9caca Compare August 23, 2023 07:55
Base automatically changed from person/aivanov/jupyter to main August 24, 2023 10:41
@antoniivanov antoniivanov enabled auto-merge (squash) August 24, 2023 10:41
@antoniivanov antoniivanov merged commit 7046a8e into main Aug 24, 2023
@antoniivanov antoniivanov deleted the person/aivanov/jupyter-ui branch August 24, 2023 10:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants