Generic OpenID Connect support

[argonaut-network]

🚀 Feature Request

Is your proposal related to a problem?

One more password. It's difficult to justify deploying a service on your network when it doesn't support your company's authentication platform. Reasons include:

• Lack of choice of authentication methods (U2F, TOTP, SMS, biometric, etc. all discarded for a simple username/password)
• Insecure due to lack of MFA (ControlPanel currently does not support MFA in any capacity, even TOTP!)
• Inability to quickly decommission users who may have administrative rights in some capacity without going down a checklist of services that don't support SSO and logging in to each one, deactivating the user, etc.
• Makes onboarding highly inefficient and prone to errors during repeated data entry
• Users can become more difficult to search for or identify, as they are allowed to customize their own user profile data

Describe the solution you'd like

Implementation of generic OpenID Connect fields to replace the built-in auth. Additionally, built-in auth should be able to be disabled entirely for improved security. The best way to do this is to configure all auth settings via an external cfg file rather than the UI, so as to skip having to create any local users to begin with.

Presumably, the first user that logs in via any authentication method will automatically become an administrator, for obvious reasons; that said, an alternative would be to import a specified group field from the OIDC provider and use that to determine user role.

Additional context

I have searched all issues and not found any that suggest this. Some folks have requested implementation of OAuth; I find OAuth 2.0 a bit simplistic, however, as methods of gathering user info from the server are nonstandard at best.

There are a number of FOSS OIDC authentication libraries for Laravel as well.

[BolverBlitz]

"Presumably, the first user that logs in via any authentication method will automatically become an administrator"

• That would Not Work because then there is No way to link the user to a pterodactyl ID

Speaking of pterodactyl: They don't support that either, so you would still have to use passwords. With the next update, CP.gg will now also update a modifyed passwort/E-Mail adress within pterodactyl, improving user experience.

[argonaut-network]

That would Not Work because then there is No way to link the user to a pterodactyl ID

There is. Storing matched pairs of user info from IdP + Pterodactyl UUIDs is one solution to this problem. Granted, an initial linking procedure would have to occur - isn't that already the case in Cp.gg?

Speaking of pterodactyl: They don't support that either, so you would still have to use passwords.

This is the larger problem. Using an IdP will not provide any kind of "password" to the application, so I'm not certain how creating/managing users in Pterodactyl would work.

Regardless, breaking Pterodactyl authentication passthrough isn't a good excuse for lack of SSO support. Anyone who's managed IT in any organization knows that SSO is mission critical, not optional. I'm not asking for a convenience/QoL feature, I'm asking for a basic security feature.

[IceToast]

There is. Storing matched pairs of user info from IdP + Pterodactyl UUIDs is one solution to this problem. Granted, an initial linking procedure would have to occur - isn't that already the case in Cp.gg?

That would require to built a system to store and match those information. This is not in the scope of this project.

This is the larger problem. Using an IdP will not provide any kind of "password" to the application, so I'm not certain how creating/managing users in Pterodactyl would work.

You are right, that is actually the biggest problem. CPGG is built on top of a piece of software (Pterodactyl), which apparently does not support SSO in any way.

Regardless, breaking Pterodactyl authentication passthrough isn't a good excuse for lack of SSO support. Anyone who's managed IT in any organization knows that SSO is mission critical, not optional. I'm not asking for a convenience/QoL feature, I'm asking for a basic security feature.

It's not an excuse if this feature would need to modify/add the exact same feature to pterodactyl too. Which is not in the scope of this project. SSO is not "critical" it is a convenience feature to not have your users login every single time they have to do something in/with/at... your organization.

Regardless if this will be worked on or not. I don't quite understand your Use-Case/Problem you are describing here. This project is not a all-in-one solution to for example a whole "hosting" company (imo). At least not yet. Implementing something extensive as SSO means there are alot more problems to be solved to be somewhat agile/flexible for every user (company) out there. -> Which requires to edit/add features to Pterodactyl too.

[snaildos]

You could use an approach like Dashactyl and generate a password for the panel. Oauth2 or OpenID connect is a +1 for large organizations.

[S0ly]

Visibly the issue have been blocked and will not be implemented in a long time if you are a big company you may have the found to pay a developer to implement this for yourself :) so im closing this issue as not planned :D