[Question] Should we turn the existing Auth0 OAuth client management code into a deployer subcommand

[GeorgianaElena]

Context

The issue with Auth0 right now is that we are encoding Auth0 config in the deployer and we are relying too much on this non open source product.

Wondering if instead of removing it as proposed in #1304, there's value in turning it into a deployer subcommand similar to the setup we have for CILogon.

One potential benefit of this one, is the username-password authentication option using Auth0's database connection (see point 3 of https://docs.2i2c.org/en/latest/admin/howto/manage-users.html#authentication) for which there's no clear easy alternative at the moment.

Proposal

Extract auth0 client creation into a deployer subcommand and add the Auth0OAuthenticator config manually instead of relying on the deployer to do it (same with what we're doing for CILogon).
We would only use this rarely when explicitely requested or when we have no alternatives and not as a default like it it right now.

Updates and actions

No response

[consideRatio]

I understand it as we planned to phase out auth0 entirely, but that its considered to meet a need for a hub that wants to self manage users without an identity provider, by offloading the password management to Auth0.

Overall, I'd greatly value reduction of complexity to favor robustness and sustainable maintenance of the complexity we comitt to having. I understand it as even if we would isolate logic related to Auth0, that we would retain significant complexity.

Here are complexities I'm considering if we would retain Auth0:

• "There are currently limited options for limiting who can sign up" (from 2i2c docs)
  I believe community representatives would absolutely require an ability to limit who is authorized, so that an self-signup can't be used directly. If we don't already feel confident Auth0 can meet the needs of robust username/password management, its more work right away for us to investigate this.
• 2i2c <-> Auth0
  We would need to manage accounts for all 2i2c engineers, retain the need to spread knowledge on how to work their UI etc even if we just use one small functionality from them. This becomes a long term maintenance commitment.
• 2i2c <-> Community representatives
  We would need to help community representatives learn how to manage users via Auth0 etc.

I think it makes sense for 2i2c to define a line that we only cross if sufficient motivation is mounted:

• 2i2c only supports CILogonOAuthenticator and GitHubOAuthenticator
• CILogonOAuthenticator can be coupled to various other identity providers
• Communities can suggest coupling to a specific identity provider via CILogon where they may have control of users themselves via username/passwords, perhaps Auth0, but the communities need to set that up themselves and not rely on 2i2c for it.

Tricky topic! I'd like to have a discussion about this in product and engineering I think, thinking that we could acquire insights about the value of supporting this vs leaving it to the communities to figure out themselves.

[GeorgianaElena]

I believe community representatives would absolutely require an ability to limit who is authorized, so that an self-signup can't be used directly. If we don't already feel confident Auth0 can meet the needs of robust username/password management, its more work right away for us to investigate this.

Yes, I'm not sure the self-signup can be restricted. The hub that we had used the Auth0 username + password was subject to crypto mining due to this particular aspect I believe, see #1216

[consideRatio]

Okay hmmm, well while it seems unclear if we should phase out Auth0 fully or not still, I see your proposal as something in the right direction no matter what.

I think you should go for this if you think its worth the time investment, because at worst its just a stop along the way that wasn't the final destination.

[damianavila]

Tricky topic! I'd like to have a discussion about this in product and engineering I think, thinking that we could acquire insights about the value of supporting this vs leaving it to the communities to figure out themselves.

I added this topic to the agenda for the next meeting.

I think you should go for this if you think its worth the time investment, because at worst its just a stop along the way that wasn't the final destination.

I concur with the idea that I see this proposal as a "deprecation process" towards the final auth0 elimination... and that feels OK to me, but let's further discuss it at the upcoming meeting!

[damianavila]

cc @2i2c-org/engineering so you are all aware of the discussion

[GeorgianaElena]

I think you should go for this if you think its worth the time investment, because at worst its just a stop along the way that wasn't the final destination.

@consideRatio, turning the current setup into a deployer subcommand was pretty straightforward https://github.com/2i2c-org/infrastructure/blob/79d5aeb6d1af3b915f7f12e2aaaab5bd69d8a410/deployer/auth0_app.py

My opinion is to currently keep it and if at the end of next quarter we managed to not need it, then just remove the script.