Add Generic Open ID Connect Support as OAuth Provider

[felixmertins]

I just had a look at the demo instance and love the work that has been done. I try to enforce SSO on every App in my cluster due to simplicities sake. However i do not use Authentik and do not want to rely on Google and Co. for OAuth. Adding Generic OIDC or Generic OAuth Support would fix this easily since almost every major Tool provides these Options and since many Implementations are already available, implementing it should probably not take too long.

I have not seen any Issues about this so i thought i would open it as a discussion and hear out your thoughts about it.

[s-anvar]

Unfortunately from my knowledge Socialite which is the package Pelican uses for OAuth does not have a generic provider rather a list of providers found here https://socialiteproviders.com/about/ that are currently implemented and can be used. You could modify Pelican to add the provider that you need, it may already be supported, which is pretty simple as long as you can follow the bouncing ball but if do decide to do that you must make sure you are following the license requirements seen here https://pelican.dev/faq/?faq=licensing as it may result in you being required to purchase a license depending on your scenario.

[Boy132]

Like mentioned above additional providers can be easily added (by plugins), as long as socialite supports the provider.
A "generic" provider won't be added.

[lusu007]

What is the current status of the plugin system? The link that a contributor posted here (#2012 (comment)) is not accessible to us.

[TubaApollo]

No idea if this changes anything about the situation with generic oauth. But it might be possible to implement this somehow without to much work involved: https://github.com/Kovah/laravel-socialite-oidc

[TubaApollo]

Just added it and works perfectly. @felixmertins although this is a few months old now. Just add the package via composer, add the schema and add one line in OAuthServiceProvider.php and that’s it.

[s-anvar]

I imagine the response will be to implement it as a plugin once the plugin system is in place.

One roadblock is the current linking flow in Pelican. It doesn’t truly support SSO only social authentication. It requires users to already have an account, then manually link an identity provider through account settings. That makes sense for social login providers like Google, Facebook, or GitHub, but not for "enterprise" identity providers like Okta, Authentik, Auth0, or Keycloak, where you control the IdP and expect a full SSO flow.

Given that, the linking system doesn’t really serve its purpose in those cases. It might make more sense to build a plugin that disables the linking flow for certain providers.