Integrate with Open WebUI Issue

[JDB321Sailor]

I provided a run down of the current and proposed changes to the Open WebUI integration documentation that is needed, to include why the change was needed, and where the reference was found. The biggest issue that is hard to identify and needs to be highlighted is that the Provider setting in the Authentik Admin UI for Open WebUI Oauth must have the encryption key left blank. Failure to do so will prevent login functionality. Additionally, there are settings that have to be configured that are not mentioned (i.e. WEBUI_URL).

Current Authentik Open WebUI Integration values:
Authentik:
Configure the Provider: provide a name (or accept the auto-provided name), the authorization flow to use for this provider, and the following required configurations.
Note the Client ID,Client Secret, and slug values because they will be required later.
Set a Strict redirect URI to https://openwebui.company/oauth/oidc/callback.
Select any available signing key.

Open WebUI
You need to set the environment variables in the appropriate place based on your deployment method—either in the .env file or as Docker environment variables. The values themselves remain the same, only their location differs.
Enter the following details from the authentik provider:
Set OAUTH_CLIENT_ID to the Client ID copied from authentik.
Set OAUTH_CLIENT_SECRET to the Client Secret copied from authentik.
Set OAUTH_PROVIDER_NAME to authentik.
Set OPENID_PROVIDER_URL to https://authentik.company/application/o/<application_slug>/.well-known/openid-configuration.
Set OPENID_REDIRECT_URI to https://openwebui.company/oauth/oidc/callback.
If you wish for new users to be created on Open Web UI, set ENABLE_OAUTH_SIGNUP to 'true'.

The proposed changes to the documenation:
Authentik:
Configure the Provider: provide a name (or accept the auto-provided name), the authorization flow to use for this provider, and the following required configurations.
Note the Client ID,Client Secret, and slug values because they will be required later.
Set a Strict redirect URI to https://openwebui.company/oauth/oidc/callback.
Select any available signing key.
Ensure no Encryption Key is selected (left blank)

Open WebUI
You need to set the environment variables in the appropriate place based on your deployment method—either in the .env file or as Docker environment variables. The values themselves remain the same, only their location differs. Ensure you have already configured the Open WebUI URL variable either in the admin settings within the Open WebUI application or via environment variable prior to enabling enabling Oauth.

Enter the following details from the authentik provider:
Set OAUTH_CLIENT_ID to the Client ID copied from authentik.
Set OAUTH_CLIENT_SECRET to the Client Secret copied from authentik.
Set OAUTH_PROVIDER_NAME to authentik.
Set OPENID_PROVIDER_URL to https://authentik.company/application/o/<application_slug>/.well-known/openid-configuration.
Set OPENID_REDIRECT_URI to https://openwebui.company/oauth/oidc/callback.
Set WEBUI_URL to https://openwebui.company
Set ENABLE_OAUTH_SIGHNUP to 'true'
Set ENABLE_LOGIN_FORM to 'false'
Set OAUTH_MERGE_ACCOUNTS_BY_EMAIL to 'true'
If you wish for new users to be created on Open Web UI, set ENABLE_OAUTH_SIGNUP to 'true' & ENABLE_LOGIN_FORM='false'
WARNING
This variable has to be set before you start using OAuth/SSO for authentication. Since this is a persistent config environment variable, you can only change it through one of the following options:
Temporarily disabling persistent config using ENABLE_PERSISTENT_CONFIG;
Changing WEBUI_URL in the admin panel > settings and changing "WebUI URL".
Failure to set WEBUI_URL before using OAuth/SSO will result in failure to log in.

the reasons for changes and justification for what was changed:
Open WebUI official environment documentation can be found at URL https://docs.openwebui.com/getting-started/env-configuration/, https://docs.openwebui.com/features/sso/#oauth2-proxy, https://docs.openwebui.com/troubleshooting/sso
The following will be pulled from that documentation as excerpts related to the changes.
ENABLE_LOGIN_FORM must be set to False when ENABLE_OAUTH_SIGNUP is set to True. Failure to do so will result in the inability to login.
WEBUI_URL
Type: str
Default: http://localhost:3000
Description: Specifies the URL where your Open WebUI installation is reachable. Needed for search engine support and OAuth/SSO.
Persistence: This environment variable is a PersistentConfig variable.
This variable has to be set before you start using OAuth/SSO for authentication. Since this is a persistent config environment variable, you can only change it through one of the following options:
Temporarily disabling persistent config using ENABLE_PERSISTENT_CONFIG;
Changing WEBUI_URL in the admin panel > settings and changing "WebUI URL".
Open WebUI integration does not support encrypted key support.

[dominic-r]

The biggest issue that is hard to identify and needs to be highlighted is that the Provider setting in the Authentik Admin UI for Open WebUI Oauth must have the encryption key left blank. Failure to do so will prevent login functionality.

integration guide says: "This documentation lists only the settings that you need to change from their default values". Considering that the encryption key is blank by default, I feel like the current notice takes care of this comment.

dditionally, there are settings that have to be configured that are not mentioned (i.e. WEBUI_URL).

Will be investigated, thank you for raising this.

_{Internal reference: AUTH-1245}

[JDB321Sailor]

integration guide says: "This documentation lists only the settings that you need to change from their default values". Considering that the encryption key is blank by default, I feel like the current notice takes care of this comment.

I agree that to someone with a in-depth knowledge of Authentik will be able to understand this, or after a deep dive of configuration documents can figure this out. Considering that you usually select both certificate options or neither one on most configuration I have come across, the exception to the rule is easier to spot when pointed out. It would have saved me, and possibly others, hours of troubleshooting to figure out.
Also, I would like to point out the flaw in your logic of the first comment, only these exact changes are required, by the immediate need to investigate an inaccuracy of information in the next comment. So a clear identification of a common mistake, would go a long way.

[dominic-r]

I see the point, but I’m inclined to keep it as is since the "defaults only" note already covers this and explicitly states that "any changes other than those explicitly mentioned in this guide could cause issues accessing your application." While I understand some may assume enabling both keys is a standard configuration at times, the guidance is clear as written. The intent here (and I would assume elsewhere as well) is that if it isn't listed, you should trust that it’s deliberate and avoid second-guessing by adding extra configuration. cc @dewi-tik and @tanberry for your view on whether this case deserves an explicit exception. Edit: Perhaps an acceptable solution could be updating the admonition type from a "note" to a "warning"?

[tanberry]

Thanks @JDB321Sailor for this Issue! When you have a chance can you take a look at the PR #16495 that @dominic-r opened in response to your Issue, and give it a review, please? I do agree that for this specific integration, we should be explicit about not adding an encryption key.. even though the blanket statement covers it, no reason not to go the extra step of telling our users about that specific field. Thanks again for your contribution!