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

[AgusTor-TRW]

Description

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

This post was originally posted to the Vikunja Community Forum

Vikunja Version

Latest

Browser and version

Firefox Latest

Can you reproduce the bug on the Vikunja demo site?

No

Screenshots

No response

[chark1es]

I dont know if this is correct, but I think its due to how the link is being parsed.

func (p *Provider) setOicdProvider() (err error) {
	p.openIDProvider, err = oidc.NewProvider(context.Background(), p.OriginalAuthURL)
	return err
}

Ill try seeing if I can test it using authentik with a port as the URL.

[kolaente]

The oidc.NewProvider will use the value that's reported by the provider on .well-known. @AgusTor-TRW what does /.well-known/openid-configuration report on your Keycloak installation?

[AgusTor-TRW]

The oidc.NewProvider will use the value that's reported by the provider on .well-known. @AgusTor-TRW what does /.well-known/openid-configuration report on your Keycloak installation?

I do not see a field declared as "provider" within the JSON response from https://[external-URL]/keycloak/realms/[domain-name]/.well-known/openid-configuration

The first few lines of the response is as follows:

    "issuer": "https://<external-url>/keycloak/realms/<domain-name>",
    "authorization_endpoint": "https://<external-url>/keycloak/realms/<domain-name>/protocol/openid-connect/auth",
    "token_endpoint": "http://<internal-url>:8080/realms/<domain-name>/protocol/openid-connect/token",
    "introspection_endpoint": "http://<internal-url>:8080/realms/<domain-name>/protocol/openid-connect/token/introspect",
    "userinfo_endpoint": "http://<internal-url>:8080/realms/<domain-name>/protocol/openid-connect/userinfo",
    "end_session_endpoint": "https://<external-url>/keycloak/realms/<domain-name>/protocol/openid-connect/logout",
    "frontchannel_logout_session_supported": true,
    "frontchannel_logout_supported": true,
    "jwks_uri": "http://<internal-url>:8080/realms/<domain-name>/protocol/openid-connect/certs",
    "check_session_iframe": "https://<external-url>/keycloak/realms/<domain-name>/protocol/openid-connect/login-status-iframe.html",

If you require more info from out openid-configuration JSON please let me know.

[kolaente]

There won't be a response field called provider in the response, but Vikunja will use the values reported by that endpoint to find the urls used to communicate with the openid provider.

My next best guess is the mixture of internal and external urls in your Keycloak configuration.

[AgusTor-TRW]

Yes, I believe that's the issue. Vikunja seems to compare the frontend URL (as received by the .well-known) to the backchannel URL (as indicated by config.yml).

I don't know if comparing them is the intended behavior when an application uses the backchannel auth per the OIDC spec but OIDC/keycloak should allow for having a different URLs

[kolaente]

To me, this looks like an edge case and a potential security issue. To Vikunja, this looks like "I made the request to this endpoint, but the response came from this other endpoint" - which it will refuse because the config says it should only be talking to the endpoint that's configured. Otherwise, it would be possible to change that endpoint on the fly, essentially doing a Man-in-the-middle attack. It's interesting that Keycloak even allows this in their config.

Is there a reason you're not using the same url for everything?

[AgusTor-TRW]

We're using the same backchannel URL for all the services hosted on our Docker container stack behind an Apache Reverse Proxy, as based on Keycloak's documentation where it can "connect with Keycloak through your local network, while the server remains publicly accessible". This also lines up with how they suggest to segment exposed paths when using a reverse proxy

Our services (such as Nextcloud, Gitea and Vikunja) don't connect out to the internet and thus have to use the internal address but the user needs to log in on a publicly available URL to actually authenticate themselves with keycloak