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

New issue

Open

opened 2026-02-27 15:00:11 -05:00 by deekerman · 10 comments

deekerman commented 2026-02-27 15:00:11 -05:00

Owner

Copy link

Originally created by @AgusTor-TRW on GitHub (Nov 25, 2024).

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

Originally created by @AgusTor-TRW on GitHub (Nov 25, 2024). ### 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](https://community.vikunja.io/t/oidc-connect-issuer-did-not-match-the-issuer-returned-by-provider/3011) ### Vikunja Version Latest ### Browser and version Firefox Latest ### Can you reproduce the bug on the Vikunja demo site? No ### Screenshots _No response_

deekerman added the

help wanted

label 2026-02-27 15:00:11 -05:00

deekerman commented 2026-02-27 15:00:17 -05:00

Author

Owner

Copy link

@chark1es commented on GitHub (Dec 6, 2024):

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.

@chark1es commented on GitHub (Dec 6, 2024): I dont know if this is correct, but I think its due to how the link is being parsed. ```go 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.

deekerman commented 2026-02-27 15:00:17 -05:00

Author

Owner

Copy link

@kolaente commented on GitHub (Dec 6, 2024):

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?

@kolaente commented on GitHub (Dec 6, 2024): 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?

deekerman commented 2026-02-27 15:00:17 -05:00

Author

Owner

Copy link

@AgusTor-TRW commented on GitHub (Dec 10, 2024):

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.

@AgusTor-TRW commented on GitHub (Dec 10, 2024): > 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: ```json "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.

deekerman commented 2026-02-27 15:00:17 -05:00

Author

Owner

Copy link

@kolaente commented on GitHub (Dec 11, 2024):

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.

@kolaente commented on GitHub (Dec 11, 2024): 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.

deekerman commented 2026-02-27 15:00:17 -05:00

Author

Owner

Copy link

@AgusTor-TRW commented on GitHub (Dec 11, 2024):

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

@AgusTor-TRW commented on GitHub (Dec 11, 2024): 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

deekerman commented 2026-02-27 15:00:17 -05:00

Author

Owner

Copy link

@kolaente commented on GitHub (Dec 11, 2024):

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?

@kolaente commented on GitHub (Dec 11, 2024): 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?

deekerman commented 2026-02-27 15:00:17 -05:00

Author

Owner

Copy link

@AgusTor-TRW commented on GitHub (Dec 11, 2024):

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

@AgusTor-TRW commented on GitHub (Dec 11, 2024): 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](https://www.keycloak.org/server/hostname) where it can "connect with Keycloak through your local network, while the server remains publicly accessible". This also lines up with how they [suggest](https://www.keycloak.org/server/reverseproxy) 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

deekerman commented 2026-02-27 15:00:17 -05:00

Author

Owner

Copy link

@AgusTor-TRW commented on GitHub (Jan 15, 2025):

Have there been any updates to this issue?

@AgusTor-TRW commented on GitHub (Jan 15, 2025): Have there been any updates to this issue?

deekerman commented 2026-02-27 15:00:17 -05:00

Author

Owner

Copy link

@TerrorBite commented on GitHub (Jan 19, 2026):

Having a similar issue here.

Setting up Vikunja as documented resulted in the following error, because Vikunja can't resolve the reverse proxy from inside Docker:
Error while getting openid provider <realm-name>: Get "https://auth.lan.<domain>/realms/<realm-name>/.well-known/openid-configuration": dial tcp <reverse-proxy-lan-ip>:443: i/o timeout

At that point I realised Vikunja was using backchannel URLs, so I changed the authurl setting to point to Keycloak directly within the cluster. That then resulted in:
Error while getting openid provider lethargiclion: oidc: issuer did not match the issuer returned by provider, expected "http://keycloak:8080/realms/<realm-name>" got "https://auth.lan.<domain>/realms/<realm-name>"

Vikunja might not be following the OIDC spec here. I would have expected Vikunja to offer separate settings for backchannel URL (the one Vikunja actually tries to connect to) versus frontchannel URL (the OIDC issuer).

The only way around this that I can see is to try and inject a DNS entry that allows Vikunja to access Keycloak through the reverse proxy. Alternatively, just use LDAP instead of OpenID Connect.

I would like to see Vikunja implement the OIDC Authorization Code Flow rather than only the OIDC Resource Owner Password Flow. This would allow Vikunja to support SSO (Single Sign-On).

@TerrorBite commented on GitHub (Jan 19, 2026): Having a similar issue here. Setting up Vikunja as documented resulted in the following error, because Vikunja can't resolve the reverse proxy from inside Docker: `Error while getting openid provider <realm-name>: Get "https://auth.lan.<domain>/realms/<realm-name>/.well-known/openid-configuration": dial tcp <reverse-proxy-lan-ip>:443: i/o timeout` At that point I realised Vikunja was using backchannel URLs, so I changed the authurl setting to point to Keycloak directly within the cluster. That then resulted in: `Error while getting openid provider lethargiclion: oidc: issuer did not match the issuer returned by provider, expected "http://keycloak:8080/realms/<realm-name>" got "https://auth.lan.<domain>/realms/<realm-name>"` Vikunja might not be following the OIDC spec here. I would have expected Vikunja to offer separate settings for backchannel URL (the one Vikunja actually tries to connect to) versus frontchannel URL (the OIDC issuer). The only way around this that I can see is to try and inject a DNS entry that allows Vikunja to access Keycloak through the reverse proxy. Alternatively, just use LDAP instead of OpenID Connect. I would like to see Vikunja implement the OIDC Authorization Code Flow rather than only the OIDC Resource Owner Password Flow. This would allow Vikunja to support SSO (Single Sign-On).

deekerman commented 2026-02-27 15:00:17 -05:00

Author

Owner

Copy link

@TerrorBite commented on GitHub (Jan 19, 2026):

I put a DNS entry into Docker, but of course Vikunja does not trust the internal CA and there seems to be no way to add a CA certificate to it. So now I am stuck at:
Error while getting openid provider <realm-name>: Get "https://auth.lan.<domain>/realms/<realm-name>/.well-known/openid-configuration": tls: failed to verify certificate: x509: certificate signed by unknown authority

Well, since my original intent in using OpenID connect was to enable SSO (which it seems Vikunja's OpenID implementation doesn't support), there is no point in pursuing OpenID Connect when I can just use LDAP auth instead.

@TerrorBite commented on GitHub (Jan 19, 2026): I put a DNS entry into Docker, but of course Vikunja does not trust the internal CA and there seems to be no way to add a CA certificate to it. So now I am stuck at: `Error while getting openid provider <realm-name>: Get "https://auth.lan.<domain>/realms/<realm-name>/.well-known/openid-configuration": tls: failed to verify certificate: x509: certificate signed by unknown authority` Well, since my original intent in using OpenID connect was to enable SSO (which it seems Vikunja's OpenID implementation doesn't support), there is no point in pursuing OpenID Connect when I can just use LDAP auth instead.

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

renovate/dev-dependencies

fix-sqlite-lock

feat-gantt-relations

fix-webhook-stale-data

feat-oauth-server

feat-event-code-shortcuts

renovate/major-tailwindcss-monorepo

feat-websocket-notifications

feat/webhooks_reminder

feat-phosphor-icons

renovate/flexsearch-0.x

wip-plans

claude/investigate-issue-2173-llKme

poc-yaegi-plugins

fix-description-text-drag

claude/csv-import-feature-01Kavsoc8Zabn7Q7WwwfVjBh

copilot/display-api-validation-errors

feat-custom-keyboard-shortcuts

feat-conversational-emails

pr-1845-ci

codex/fix-drag-and-drop-behavior-inconsistency

copilot/add-clickable-labels-for-filtering

copilot/fix-issue-1786

claude/fix-duplicate-close-button-mobile-011CUfbqZNZYoki8vXzWMGFS

playwright-migration

fix-kanban-repeating-wip

fix-all-typescript-issues

copilot/fix-1498

codex/analyze-codebase-for-email-task-feature

feature/replace-axios

codex/add-task-sorting-functionality

upgrade-tailwind-4

codex/upgrade-to-tailwind-4.1.8-using-pnpm

codex/add-cypress-test-for-avatar-types

feature/biome

feature/oxc

codex/update-flexsearch-to-0.8.205

4r6ni9-codex/fix-deprecated-sass-@import-usage

codex/fix-deprecated-sass-@import-usage

codex/add-cypress-test-for-task-list-refresh-fix

codex/fix-quick-add-magic-not-adding-tasks

codex/fix-all-type-errors

codex/fix-mimetype-for-docs.json

feature/caldav-from-scratch

feature/gh-actions-hetzner

fix-ci

feat/new-logger

jyte-better-dev-config

feat/add-team-member-with-enter

fix/button-and-icon-types

fix/notifications-component-name-collision

feature/null-time

renovate/tailwindcss-4.x

feature/unplugin-vue-router

fix/deprecated-import

feature/zod-schema

renovate/golangci-golangci-lint-1.x

fix/tiptap-editor-reactive-destructuring

release/0.24

feat/improve-add-task

fix/saved-filter-search

feature/use-modern-compiler-for-sass-files-as-well

feat/webp-and-avif-attachment-previews

feature/migrate-back-to-bulma

fix/sass-add-missing-list-import

feature/sticky-demo-bar

fix/gantt-view-switch

feature/typesense-position-join

feature/focus-visible

dependencies/golangci-lint

feature/better-filter-syntax

fix/tiptap-task-list

renovate/github.com-golang-jwt-jwt-v4-5.x

feature/hide-forbidden-related-tasks

renovate/golang-1.x

release/0.20

release/0.17

release/0.16

release/0.15

release/0.14

release/0.13

v2.1.0

v2.0.0

v1.1.0

v1.0.0

v1.0.0-rc4

v1.0.0-rc3

v1.0.0-rc2

v1.0.0-rc1

Labels

Clear labels   

area/api

  

area/caldav

  

area/filters

  

area/frontend

  

area/gantt

  

area/internal-code

  

area/typesense

  

bug

  

changes requested

  

confirmed

  

dependencies

  

enhancement

  

good first issue

  

help wanted

  

kind/bug

  

kind/feature

  

needs reproduction

  

question

  

security

  

support

  

upstream issue

  

waiting for reply

  

wontfix

No labels

area/api

area/caldav

area/filters

area/frontend

area/gantt

area/internal-code

area/typesense

bug

changes requested

confirmed

dependencies

enhancement

good first issue

help wanted

kind/bug

kind/feature

needs reproduction

question

security

support

upstream issue

waiting for reply

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/vikunja-go-vikunja#318

No description provided.