feat: add generic OIDC connect

[muhlba91]

This PR adds support for a generic OIDC authentication. Users can login and also signup using a custom OIDC server.

Administrators can deploy this by setting OIDC_CLIENT_ID , and the following environment variables are available to configure the OIDC flow:

• CONNECT_WITH_OIDC_ICON: the icon to be shown in the UI
• OIDC_AUTHORIZATION_URL: the OIDC auth endpoint
• OIDC_USER_INFO_URL: the OIDC user info endpoint to retrieve the user's email and name (if signing up)
• OIDC_TOKEN_URL: the OIDC token endpoint to exchange the code for a valid token
• OIDC_SCOPES: the OIDC scopes to use for performing the request
• OIDC_NAME_FIELD: the field containing the user's name (used for sign-up)
• OIDC_CLIENT_ID: the OIDC client id
• OIDC_CLIENT_SECRET: the OIDC client secret

This is based in the discussion in #1425 (comment).

[nguyenkims]

I just left some comments.

[acasajus]

Hey, thanks for the contribution. As a general rule we'd like to have tests for new code that's merged into the repo to make sure that:

• the feature works as expected
• future changes don't break it.

Would you mind adding tests to it?

[muhlba91]

@acasajus @nguyenkims thank you for your review and comments! 😃
i have fixed your findings and added tests for the oidc.py methods.

[muhlba91]

@nguyenkims @acasajus bumping this one again - would you be able to review again and get it into main? 😃

[acasajus]

Hey. LGTM! Let's merge 👍

[Queuecumber]

So happy to see this merged! I'm going to close my PR for external auth since this should cover it

Would this be available in a docker container soon?

[acasajus]

Should be already in the v4.41.2

[Queuecumber]

Hey I just wanted to leave some feedback that over all this works well

To make it work with Google I did have to set the environment variable OAUTHLIB_RELAX_TOKEN_SCOPE otherwise I would get a warning because apparently google changes the order of the oauth scopes and that causes an exception to be thrown. I'm not entirely sure if there's a way to fix this in code or not.

Also a lot of the environment variables can/should probably be read from the .well-known (https://accounts.google.com/.well-known/openid-configuration for example) rather than read manually

[muhlba91]

@Queuecumber thank you for that feedback and info with the well-known endpoint!

do you happen to know if all OIDC provider must implement that well-known endpoint, meaning it's part of the specification?
the reason why i ask is that i would rather not like to rely reading from it if that means we potentially make it incompatible with some providers, whether self-hosted or not.
otherwise, i can see if the used oauth lib supports setting and reading from that endpoint.

[Queuecumber]

Here's the spec for it: https://openid.net/specs/openid-connect-discovery-1_0.html

It's unclear if this is mandatory for the provider to implement, it is certainly optional for the RP (see Sec. 2). Google, for example, says applications should use the well-known endpoint. The advantage is that if they change one of the underlying URLs it will be reflected in the well-known endpoint without needing to reconfigure the application. The well-known endpoint shouldn't (ideally) change. It's also a lot less typing to set up.

The way I usually see this implemented is that the user can either fill out all the fields manually (i.e., what we have now) OR they can give just the well-known URL and have the application discover the endpoints.

[muhlba91]

thank you! 👍🏻

i like your proposal of deciding it dynamically based on whether the well-known endpoint is given or not.

currently, i'm on travel but i'll see how i can integrate that! 😃

[Queuecumber]

Awesome thanks, I did poke around and I don't think requests_oauthlib has support for it, but that may be intentional since it's just a simple API call and JSON parse to get the info

I'm also noticing an error when the callback URL has a query string on it, like https://<redacted>/auth/oidc/callback?next=%2Fdashboard%2F is a common one. It seems like you're not supposed to include those parameters in the query string of the callback, I can file a bug for this to keep things cleaner.

[viq]

FWIW (which isn't necessarily much), from quickly checking the docs, following Open Source OIDC providers (that I could think of) do expose the .well-known endpoint:

• Keycloak
• Authentik
• Dex
• ORY Hydra
• OIDC connector for NextCloud
• HashiCorp Vault
• GitLab

[viq]

Awesome thanks, I did poke around and I don't think requests_oauthlib has support for it, but that may be intentional since it's just a simple API call and JSON parse to get the info

Looks like it may not, but from a quick search, authlib in their docs for OAuth2 say:

This documentation covers the common design of a Python OAuth 2.0 client. Authlib provides three implementations of OAuth 2.0 client:

1. requests_client.OAuth2Session implementation of OAuth for Requests, which is a replacement for requests-oauthlib.

and this example suggests they do support discovery via .well-known.

[muhlba91]

#2077 should 1/ fix the redirect URL issue, and 2/ adds support for the OIDC well-known endpoint. as discussed, the endpoint takes precedence over all env variables but is an optional var.