OIDC Connect - issuer did not match the issuer returned by provider

Greetings,

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)

Our configuration for Vikunja is as follows:

auth:
  local:
    enabled: false
  openid:
    enabled: true
    redirecturl: https://<external-vikunja-url>/auth/openid/
    providers:
      - name: keycloak
        authurl: http://<internal-keycloak-address>:8080/realms/<realm-name>
        logouturl: http://<internal-keycloak-address>:8080/realms/<realm-name>/protocol/openid-connect/logout
        clientid: <vikunja-clientid>
        clientsecret: <vikunja-clientsecret>
        scope: openid profile email
  defaultsettings:
    - week_start: 0

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.)

Thank you in advance

looks like your mixing protocols:

[/quote]

I think this may be the error

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).

in my setup, I have my url’s in double quotes, and clientid and clientsecret without:

authurl: "https://tld..."
logouturl: "https://tld..."
clientid: asldkfj;asdlkfj
clientsecret: asldkfjas;dlkfj

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>

Where do you recieve that error? I assume in the web, but I just want to make sure.

Could you share your Vikunja Logs?

We see the error from the container’s log, here’s the latest attempt:

1efb2a2e450b 2024-11-18T19:16:20.672748139Z 2024-11-18T19:16:20Z: INFO  ▶ 001 Using config file: /etc/vikunja/config.yml
1efb2a2e450b 2024-11-18T19:16:20.673235230Z 2024-11-18T19:16:20Z: INFO  ▶ 002 Running migrations…
1efb2a2e450b 2024-11-18T19:16:20.715691934Z 2024-11-18T19:16:20Z: INFO  ▶ 06a Ran all migrations successfully.
1efb2a2e450b 2024-11-18T19:16:20.715691934Z 2024-11-18T19:16:20Z: INFO  ▶ 06b Mailer is disabled, not sending reminders per mail
1efb2a2e450b 2024-11-18T19:16:20.715739252Z 2024-11-18T19:16:20Z: INFO  ▶ 06c Mailer is disabled, not sending overdue per mail
1efb2a2e450b 2024-11-18T19:16:20.715833598Z 2024-11-18T19:16:20Z: INFO  ▶ 06d Vikunja version v0.24.4
1efb2a2e450b 2024-11-18T19:16:20.717312262Z ⇨ http server started on [::]:3456
1efb2a2e450b 2024-11-18T19:16:34.878927643Z 2024-11-18T19:16:34Z: WEB   ▶ <ip-address>  GET 200 /login 437.468µs - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:132.0) Gecko/20100101 Firefox/132.0
1efb2a2e450b 2024-11-18T19:16:35.197218683Z 2024-11-18T19:16:35Z: WEB   ▶ <ip-address>  GET 200 /assets/index-BdIWn3Ve.js 38.825476ms - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:132.0) Gecko/20100101 Firefox/132.0
1efb2a2e450b 2024-11-18T19:16:41.034233528Z 2024-11-18T19:16:41Z: WEB   ▶ <ip-address>  GET 200 /assets/index-i4VRmjeA.css 11.73615ms - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:132.0) Gecko/20100101 Firefox/132.0
1efb2a2e450b 2024-11-18T19:16:41.697841520Z 2024-11-18T19:16:41Z: WEB   ▶ <ip-address>  GET 200 /favicon.ico 1.360874ms - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:132.0) Gecko/20100101 Firefox/132.0
1efb2a2e450b 2024-11-18T19:16:41.923379629Z 2024-11-18T19:16:41Z: WEB   ▶ <ip-address>  GET 200 /assets/OpenSans_wght__54a65da5-BSoKZk7G.woff2 214.682µs - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:132.0) Gecko/20100101 Firefox/132.0
1efb2a2e450b 2024-11-18T19:16:42.149494334Z 2024-11-18T19:16:42Z: ERROR ▶ 0e9 Error while getting openid provider keycloak: oidc: issuer did not match the issuer returned by provider, expected "http://<keycloak-internal>:8080/realms/<realm-name>" got "https://<keycloak-external>/keycloak/realms/<realm-name>"
1efb2a2e450b 2024-11-18T19:16:42.149776932Z 2024-11-18T19:16:42Z: WEB   ▶ <ip-address>  GET 200 /api/v1/info 4.800643ms - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:132.0) Gecko/20100101 Firefox/132.0
1efb2a2e450b 2024-11-18T19:16:42.155892153Z 2024-11-18T19:16:42Z: WEB   ▶ <ip-address>  GET 200 /images/icons/apple-touch-icon-180x180.png 318.866µs - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:132.0) Gecko/20100101 Firefox/132.0
1efb2a2e450b 2024-11-18T19:16:42.258978141Z 2024-11-18T19:16:42Z: WEB   ▶ <ip-address>  GET 200 /assets/llama-nightscape-mKZQPxXM.jpg 2.912033ms - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:132.0) Gecko/20100101 Firefox/132.0
1efb2a2e450b 2024-11-18T19:16:42.421755591Z 2024-11-18T19:16:42Z: WEB   ▶ <ip-address>  GET 200 /assets/llama-SxB1d0EY.svg?url 429.794µs - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:132.0) Gecko/20100101 Firefox/132.0
1efb2a2e450b 2024-11-18T19:16:42.422335796Z 2024-11-18T19:16:42Z: WEB   ▶ <ip-address>  GET 200 /assets/Quicksand_wght__87bdcc7f-CH4TLDJK.woff2 225.52µs - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:132.0) Gecko/20100101 Firefox/132.0
1efb2a2e450b 2024-11-18T19:16:42.430243979Z 2024-11-18T19:16:42Z: WEB   ▶ <ip-address>  GET 200 /assets/no-auth-image-B3TdQwHl.jpg 8.134144ms - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:132.0) Gecko/20100101 Firefox/132.0

From the website, this is all that’s shown when the error gets logged:

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

We tried different options but no luck:

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

From Keycloak we only note the following log that occurs right when Vikunja returns the error:

4b29fb376251 2024-11-20T11:53:16.583992341Z 2024-11-20 11:53:16,583 DEBUG [io.quarkus.vertx.http.runtime.ForwardedParser] (executor-thread-24) Recalculated absoluteURI to http://<internal-keycloak-address>:8080/realms/<realm-name>/.well-known/openid-configuration

Found this on the doc page:

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 :crossed_fingers:t2:

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.

Hello again,

In addition to this post, I have opened a Github issue:

Pinging @Wasabi since you’re using Keycloack as well iirc?

Hey there,

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.