github-starred/vikunja
2
0
Fork 0
mirror of https://github.com/go-vikunja/vikunja.git synced 2026-07-15 22:32:29 -05:00
Code Issues 690 Packages Projects Releases 11 Wiki Activity

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

New Issue
Open
opened 2025-11-01 20:53:43 -05:00 by GiteaMirror · 8 comments
GiteaMirror commented 2025-11-01 20:53:43 -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_
GiteaMirror added the help wanted label 2025-11-01 20:53:43 -05:00
GiteaMirror commented 2025-11-01 20:53:44 -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.
GiteaMirror commented 2025-11-01 20:53:44 -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?
GiteaMirror commented 2025-11-01 20:53:45 -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.
GiteaMirror commented 2025-11-01 20:53:45 -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.
GiteaMirror commented 2025-11-01 20:53:45 -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
GiteaMirror commented 2025-11-01 20:53:45 -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?
GiteaMirror commented 2025-11-01 20:53:45 -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
GiteaMirror commented 2025-11-01 20:53:46 -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?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
area/attachments
area/auth
area/avatars
area/backup-restore
area/caldav
area/calendar-view
area/comments
area/config
area/database
area/desktop
area/docker
area/email
area/favorites
area/filters
area/frontend
area/gantt
area/i18n
area/import-export
area/internal-code
area/kanban
area/labels
area/list-view
area/mobile
area/notifications
area/permissions
area/projects
area/pwa
area/recurring-tasks
area/reminders
area/search
area/shortcuts
area/subtasks
area/sync
area/table-view
area/task-editor
area/task-metadata
area/task-relations
area/teams
area/theming
area/time-tracking
area/typesense
area/views
area/webhooks
bug
changes requested
concern/accessibility
concern/performance
concern/regression
concern/ux
confirmed
db/mysql
dependencies
enhancement
good first issue
help wanted
integration/inbound
integration/outbound
kind/bug
kind/feature
needs reproduction
pull-request
Mirrored from GitHub Pull Request
 question
security
support
upstream issue
waiting for reply
wontfix
No Label help wanted
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vikunja#318
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?