We’ve recently installed Vikunja within our Docker Container stack after testing out its functionalities and we’ve noticed the following issue with connecting Vikunja to Keycloak via internal address (as declared in Keycloak, the backend URL)
All of our services exist within the same docker network and have no problem connecting and authenticating with Keycloak, however when attempting the same configuration with Vikunja, we recieve the following error:
Error while getting openid provider keycloak: oidc: issuer did not match the issuer returned by provider, expected "http://<internal-keycloak-address>:8080/realms/<realm-name>" got "https://<external-keycloak-address>/keycloak/realms/<realm-name>"
From our testing, we noted that Vikunja attempts to connect to the external Keycloak URL (taken from the response from the discovery URL) when we switch the Keycloak frontend URL to be the same as the internal address within Keycloak’s configuration, Vikunja no longer reports the error but Keycloak can no longer authenticate/redirect due to being on an address inaccessible from the outside. This obviously breaks authentication for all the other services as they are not directly accessible from the outside and only redirected using an Apache Reverse Proxy. (For example, we also host a Gitea thats configured to authenticate with Keycloak using the internal URL which works fine with the current setup)
We are not certain if it’s a misconfiguration on our end, a bug with vikunja or maybe Vikunja following the OIDC spec alot more strictly than the rest of our services that are working (Gitea, Nextcloud, etc.)
We tried that, however the result was the same as this error occurs when Vikunja attempts to validate the authurl against the provider’s URL which, according to our Keycloak’s configuration, the frontchannel URL and not the backchannel URL. We also validated this by changing our frontchannel URL to be the internal one, fixing the error but breaking the rest of the auth flow due to being inaccessible from outside connections.
We have other services on our docker network that are hosted in the same way as Vikunja, behind an Apache Reverse Proxy (Gitea and Nextcloud) all authenticating successfully using the internal discovery URL (http://:8080/realms//.well-known/openid-configuration).
I personally user Nginx Proxy Manager and authentik, so my setup is a bit different, but do you have a proxy pass setup? Or do you require an additional config on your Apache? NPM has an Advanced Config tab that i had to tinker with to get my instance running properly.
I have my url’s in double quotes, and clientid and clientsecret without
Thanks for the suggestion, I was unaware that using double or single quotes was allowed in Vikunja’s configuration file. Unfortunately trying either still result in the same error “issuer did not match the issuer returned by provider”.
but do you have a proxy pass setup? Or do you require an additional config on your Apache?
Yes, here’s our Apache configuration for Vikunja:
<VirtualHost *:443>
ServerName <external-vikunja-url>
SSLProxyCheckPeerCN on
SSLProxyCheckPeerExpire on
ProxyRequests Off
SSLEngine on
SSLCertificateFile "<cert.pem>"
SSLCertificateKeyFile "<key.pem>"
SSLCertificateChainFile "<fullchain.pem>"
SSLCACertificatePath "<path/to/certs>"
SSLCACertificateFile "<fullchain.pem>"
ProxyPreserveHost on
AllowEncodedSlashes NoDecode
RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
Header set Content-Security-Policy "frame-ancestors 'self' <domain>"
ProxyPass / http://<internal-vikunja>:3456/
ProxyPassReverse / http://<internal-vikunja>:3456/
</VirtualHost>
You should also see the “login with…” on your frontpage
here is my config:
auth:
# Local authentication will let users log in and register (if enabled) through the db.
# This is the default auth mechanism and does not require any additional configuration.
local:
# Enable or disable local authentication
enabled: false
# OpenID configuration will allow users to authenticate through a third-party OpenID Connect compatible provider.<br/>
# The provider needs to support the `openid`, `profile` and `email` scopes.<br/>
# **Note:** Some openid providers (like gitlab) only make the email of the user available through openid claims if they have set it to be publicly visible.
# If the email is not public in those cases, authenticating will fail.
# **Note 2:** The frontend expects to be redirected after authentication by the third party
# to <frontend-url>/auth/openid/<auth key>. Please make sure to configure the redirect url with your third party
# auth service accordingly if you're using the default Vikunja frontend.
# Take a look at the [default config file](https://github.com/go-vikunja/api/blob/main/config.yml.sample) for more information about how to configure openid authentication.
openid:
# Enable or disable OpenID Connect authentication
enabled: true
#redirecturl: "https://TLD/auth/openid/"
# A list of enabled providers
providers:
# The name of the provider as it will appear in the frontend.
- name: "authentik"
# The auth url to send users to if they want to authenticate using OpenID Connect.
authurl: "https://TLD/application/o/vikunja/"
logouturl: "https://TLD/application/o/vikunja/end-session/"
# The client ID used to authenticate Vikunja at the OpenID Connect provider.
clientid: noQuotesHere
# The client secret used to authenticate Vikunja at the OpenID Connect provider.
clientsecret: noQuotesHere
scope: openid email profile vikunja_scope
EDIT:
I would also check your Keycloak, I had to add an additional redirect URI
this is using the - name: "authentik" field from the config as the slug. This is one of the places I had issue when I was setting up mu oidc. May be similar for Keycloak
The “Login with…” message only appears when the connection to keycloak is successful, which is what we saw when we temporarily changed the frontchannel URL to the internal one.
I would also check your Keycloak, I had to add an additional redirect URI
What does your Keycloak logs have when trying to connect? with the error it looks like you are hitting Keycloak but it isn’t returning properly. I think I had this issue when setting up Jelu, but its been so long and I didn’t notate the issue well in my notes
Note: The authurl that Vikunja requires is not the Authorize URL that you can see in the Provider. OpenID Discovery is used to find the correct endpoint to use automatically, by accessing the OpenID Configuration URL (usually https://authentik.mydomain.com/application/o/vikunja/.well-known/openid-configuration). Use this URL without the .well-known/openid-configuration as the authurl. Typically, this URL can be found in the metadata section within your identity provider.
Looks like this may actually be the solution
when comparing the URL’s in config, it seems i setup my authurl this way and you did not.
EDIT:
I do notice this is for Authentik only, but as a last ditch, and what your logs in keycloak show, i figured it was worth a shot
Yes, we found that out when we first tried http://<internal-keycloak-address>:8080/realms/<realm-name>/.well-known/openid-configuration and that didn’t work and results in the following error: 2d74fc8ef27b 2024-11-20T15:06:39.812688840Z 2024-11-20T15:06:39Z: ERROR ▶ 0e9 Error while getting openid provider keycloak: 404 Not Found: {"error":"Unable to find matching target resource method","error_description":"For more on this error consult the server log at the debug level."}.
Then we found this post from March 9th of this year (2024) that mentioned something similar for Keycloak, that is when we changed our authurl to http://<internal-keycloak-address>:8080/realms/<realm-name>/. This changed the error message to the current one and where we find ourselves today.
yes I’m using Keycloak as well, however we don’t use a separate backend URL for this. Frontend traffic (user authentication) and backend traffic uses the same URL published using a reverse proxy.
I cannot promise when I’ll get to it, but I can try to have a look. Not entire sure about the OIDC spec and Keycloak behaviour, this one might require a bit of digging.
Thank you @kolaente and @Wasabi for looking into this. I shall be monitoring this thread and the Github issue in case you need any logs or configs from my end to help narrow this down.
