OAuth provider: Auth0

[qrkourier]

Currently supported OIDC providers are Google, GitHub

Enabling Auth0 would allow a single OAuth provider configuration to support all the providers supported by Auth0 transitively

Personally, I'd prefer to have Auth0 before Okta because Auth0 allows the use of their own third-party client id/client secret, e.g. Google OAuth account, which is convenient for development and tiny scale testing.

With Okta, it's necessary to set up my own Google client id/secret, which is limited to allowed email addresses, so it's considerably more work for the dev to get things running.

[lukasmrtvy]

I would suggest https://github.com/dexidp/dex

[qrkourier]

@lukasmrtvy Correct me if this saved-you-a-click summary is inaccurate.

It looks like Dex could accelerate zrok compatibility with many OIDC providers, which is in the same spirit as the idea of adding an Auth0 implementation.

Supporting Dex would mean deploying zrok and Dex in tandem, Dex would replace the zrok frontend's OAuth endpoint that currently listens on a discrete port and is typically reached through a separate domain name like oauth.{{zrok_zone}}.

Instead of an OIDC implementation for each provider (google.go, github.go), zrok would have a single implementation for Dex (dex.go), and Dex would hold all OIDC client id/secret creds for providers (Auth0 [an example of a transitive provider], Google, Github, etc.).

[lukasmrtvy]

oidc.go ( https://github.com/coreos/go-oidc ) generic OIDC provider has to be introduced, with dexidp in tandem one would have the option to "plug-in" other providers

[maltegrosse]

would be great to see go-oidc used here (similar headscale is doing it) - so I could add my keycloak oidc....

[icsy7867]

Adding here as well, would also love to see a generic OIDC provider, so that I can use my organizations SSO capabilities.