Investigate authenticating GitHub Orgs/Teams through Auth0

[sgibson91]

Description

Over in #625, the question was raised whether we could facilitate authentication against GitHub Orgs and Teams via our current Auth0 setup. If it's possible, it would save us a lot of manual work in creating GitHub OAuth Apps, storing secrets, and allow us to continue using the infrastructure we have in place for Auth0 support.

Something we should think about while investigating this: The 2i2c Engineering team like to use Auth0 as it saves us the toil of creating IDs and secrets for various auth apps. Thinking with our Right to Replicate hat on, is there a benefit for a Hub Community (managing their own hub) to use this Auth0 as a pass-through to GitHub-based auth beyond the ID/secrets argument, especially given the more familiar setup using the native JupyterHub OAuthenticator? By folding this into our Auth0 setup, do we raise the barrier to a community replicating their infrastructure without 2i2c assistance?

Value / benefit

• Reduced toil for 2i2c Engineers
• A single authentication story across all hubs

Implementation details

As a point of reference, the Pangeo community did a bit of discussion around this topic as well.

• Here's the original issue where they discussed Auth0
• Though their implementation ended up using a lot of custom Javascript that may not be portable to other usecases.

When to check in on this

We need to gain some experience with our current "native JupyterHub" setup, to understand how much maintenance work it is and whether it is scalable. We should re-visit this issue around February 2022 (unless something escalates it earlier) to decide whether our current setup works well.

Tasks to complete

No response

Updates

No response

[choldgraf]

The main thing that made me think we might want to suggest that other organizations use Auth0 is that the Pangeo community was already using Auth0 by their own decision, weren't they? pangeo-data/pangeo-cloud-federation#611

I think that there are probably different answers depending on the hub community size, but for communities of a decent amount of complexity, Auth0 seems to be a reasonable solution.

[sgibson91]

The main thing that made me think we might want to suggest that other organizations use Auth0 is that the Pangeo community was already using Auth0 by their own decision, weren't they? pangeo-data/pangeo-cloud-federation#611

They also had this issue though jupyterhub/oauthenticator#265

And their auth0 setup involved a lot of custom Javascript https://github.com/pangeo-data/pangeo-cloud-federation/tree/prod/auth0 Do we have the skills on the team to maintain that sustainably? (I don't even have the skills to reimplement it)

If there's a way to achieve it without Javascript, that'd be interesting

[choldgraf]

@sgibson91 thanks for that extra context - that is definitely important follow-up.

Agreed that if using Auth0 also requires using a ton of custom JS, it's probably not something we can recommend.

Would this be a reasonable guideline:

• For lightweight or straightforward authentication needs, Auth0 is reasonable
• For anything more complex, use a native authenticator

?

[sgibson91]

• For lightweight or straightforward authentication needs, Auth0 is reasonable
• For anything more complex, use a native authenticator

Yes, this was pretty much what I was recommending in my design proposal, that using native JupyterHub OAuth is the exception to the rule :)

[choldgraf]

Cool - I agree w/ your assessment then :-)

IMO I kinda feel like we should just consider this issue as "resolved". Unless we can think of an easy way to support this with Auth0 without using a bunch of JS, then IMO we should just follow the approach you laid out. What do you think?

[sgibson91]

Unless we can think of an easy way to support this with Auth0 without using a bunch of JS

Tbh, I haven't done the work to look into this yet, I went straight to the Jupyter OAuthenticator. In my mind, this issue is here to track that work over longer term if and when we find ourselves being overwhelmed by manually creating GitHub OAuth Apps. Maybe I didn't write the issue up clearly enough though?

[choldgraf]

that makes sense - maybe we should time-box this then? E.g., in 9 months check whether we want to re-explore with Auth0? I just worry that we'll lose track of this issue since it's not something we'll take action on any time soon until we've had more experience with the current workflow

[sgibson91]

It would be good to hear from Pangeo folk like @scottyhq if they think using Auth0 with GitHub Teams is possible without all the Javascript given enough dev time?

[sgibson91]

I just worry that we'll lose track of this issue since it's not something we'll take action on any time soon until we've had more experience with the current workflow

For sure, but I was also worried that if we didn't have an issue saying "this is something to explore regarding this problem" open in the future when we may need it, dragging out the info from closed issues/PRs would be harder 😅

[choldgraf]

Indeed! OK I've added a short note about checking back in on this to the top comment 👍

[damianavila]

In my mind, this issue is here to track that work over longer term if and when we find ourselves being overwhelmed by manually creating GitHub OAuth Apps.

I think this is the proper approach!

Btw, those JS pieces do not seem particularly complex, I would be more worried about using the concept of Auth "rules" regardless of the language it is implemented... I feel it might increase the risk surface and I am not sure about the limitations neither the easiness to work with them.

[scottyhq]

It would be good to hear from Pangeo folk like @scottyhq if they think using Auth0 with GitHub Teams is possible without all the Javascript given enough dev time?

Thanks for all the work you're doing on this! i'm sure there are lots of options on how these things are implemented, in case it helps i'll just provide a bit of context on the current setup:

• we started using auth0 to make an attempt at easier user management (let's say we want to email all users of the GCP hub, we didn't have an easy way of doing that w/ standard github auth at the time). Teams-based access rules was an experiment that seemed useful, and i just copied this example since I don't know much JS :) https://gist.github.com/aslafy-z/4c4f73aa24bbeb4a59e8d6bc849cd1ba

• The only time i've actually used Auth0 for user management was to block a specific bitcoin user/bot on the aws pangeo binder which uses github auth (but is open to any github user) temporarily disabled aws binder due to bitcoin mining pangeo-data/pangeo-binder#188 (comment)

• whether it's Auth0 or something else it's really nice to have:

  1. a user database that a hub admin can easily navigate
  2. the ability to add and block users without modifying configuration code or yamls.

• Somewhat related... During our move to Auth0 we also added this GitHub Action that automatically adds people to a pangeo-data org team based on their pangeo cloud google form application, and that has proven really useful so that we don't have to manually add users to the pangeo-data github org as we did in the past. https://github.com/pangeo-data/pangeo-cloud-federation/blob/staging/.github/workflows/UpdateMembers.yml

[yuvipanda]

I think we have basically now moved to using GitHub authentication directly, and support Organizations / team based auth. We also support per-team profiles! Closing this one.