Unable to setup OpenID login

[ngthwi]

Description

I can't enable the OpenID login. I have deployed Vikunja in docker and I am using a config.yml in /etc/vikunja (I've also tried to set the env variable VIKUNJA_AUTH_OPENID: true) The config.yml has basically only the following lines as I assume they override the base parameters.

auth:
  local:
    enabled: true
  openid:
    enabled: true
    redirecturl: https://vikunja.domain.com/auth/openid/
    providers:
      - name: someProvider
        authurl: https://my.domain.com/sso
        logouturl:
        clientid: someClientID
        clientsecret: someClientSecret
        scope: openid email profile

No OpenID button on the home page...

The config.yml seems to work as I am able to disable the local login. Here's the result with the following params:

auth:
  local:
    enabled: false #####
  openid:
    enabled: true #####
    redirecturl: https://vikunja.domain.com/auth/openid/
    providers:
      - name: someProvider
        authurl: https://my.domain.com/sso
        logouturl:
        clientid: someClientID
        clientsecret: someClientSecret
        scope: openid email profile

Resulting info page

Resulting home page

Thanks for your help

Vikunja Version

v0.23.0

Browser and version

No response

Can you reproduce the bug on the Vikunja demo site?

No

Screenshots

No response

[kolaente]

Do you see anything in the logs when you enable the provider, restart Vikunja and then access the /api/v1/info endpoint?

[ngthwi]

No error in the logs

[kolaente]

What's the output after the "http server started" line? Vikunja will fetch the providers the first time you access the /info endpoint it, it can only do that once the http server is running.

[ngthwi]

Here's the log

info: creating the new user vikunja with xxxx:xxx
usermod: no changes
2024-03-19T15:31:41.611530562Z: INFO    ▶ config/InitConfig 001 Using config file: /etc/vikunja/config.yml
2024-03-19T15:31:42.946249657Z: INFO    ▶ migration/Migrate 05b Ran all migrations successfully.
2024-03-19T15:31:42.946479645Z: INFO    ▶ models/RegisterReminderCron 05c Mailer is disabled, not sending reminders per mail
2024-03-19T15:31:42.946584904Z: INFO    ▶ models/RegisterOverdueReminderCron 05d Mailer is disabled, not sending overdue per mail
2024-03-19T15:31:42.94680339Z: INFO ▶ cmd/func29 05e Vikunja version v0.23.0
⇨ http server started on [::]:3456
2024-03-19T15:32:26.163664972Z: WEB     ▶ xxx.xxx.xxx.xxx  GET 200 /api/v1/info 789.836µs - Mozilla/5.0 xxxxx
2024-03-19T15:32:26.546023266Z: WEB     ▶ xxx.xxx.xxx.xxx  GET 200 /favicon.ico 19.159781ms - Mozilla/5.0 xxxxx

[ngthwi]

info: creating the new user vikunja with xxxx:xxxx
2024-03-20T08:26:09.119360933+01:00: INFO▶ config/InitConfig 001 Using config file: /etc/vikunja/config.yml
2024-03-20T08:27:57.360870859+01:00: INFO▶ migration/Migrate 0c0 Ran all migrations successfully.
2024-03-20T08:27:57.376972531+01:00: INFO▶ models/RegisterReminderCron 0c1 Mailer is disabled, not sending reminders per mail
2024-03-20T08:27:57.390943622+01:00: INFO▶ models/RegisterOverdueReminderCron 0c2 Mailer is disabled, not sending overdue per mail
2024-03-20T08:27:57.39117857+01:00: INFO▶ cmd/func29 0c3 Vikunja version v0.23.0
⇨ http server started on [::]:3456
2024-03-20T08:28:14.944360685+01:00: WEB ▶ xxx.xxx.xxx.xxx  GET 200 / 1.583714ms - Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.3.1 Safari/605.1.15
2024-03-20T08:28:15.464595931+01:00: WEB ▶ xxx.xxx.xxx.xxx  GET 200 /manifest.webmanifest 117.939071ms - Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.3.1 Safari/605.1.15
2024-03-20T08:28:15.490077847+01:00: WEB ▶ xxx.xxx.xxx.xxx  GET 200 /assets/index-VlJ-wnF6.css 146.723855ms - Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.3.1 Safari/605.1.15
2024-03-20T08:28:15.510011199+01:00: WEB ▶ xxx.xxx.xxx.xxx  GET 200 /assets/index-9Lu9q13r.js 166.844681ms - Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.3.1 Safari/605.1.15
2024-03-20T08:28:15.701739203+01:00: WEB ▶ xxx.xxx.xxx.xxx  GET 200 /assets/OpenSans_wght__54a65da5-UqCmZOxj.woff2 114.832448ms - Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.3.1 Safari/605.1.15
2024-03-20T08:28:15.959653975+01:00: WEB ▶ xxx.xxx.xxx.xxx  GET 200 /assets/fr-FR-T0Iw2l6H.js 120.263616ms - Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.3.1 Safari/605.1.15
2024-03-20T08:28:16.017561473+01:00: WEB ▶ xxx.xxx.xxx.xxx  GET 200 /api/v1/info 572.441µs - Mozilla/5.0  (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.3.1 Safari/605.1.15

[kolaente]

But with that, does the openid provider show up on the login page? Does it show up when you access /api/v1/info in a browser?

[ngthwi]

openid:
    enabled: true #####

is completely ignored while

local:
    enabled: false #####

is correctly taken in account...

[ngthwi]

But with that, does the openid provider show up on the login page? Does it show up when you access /api/v1/info in a browser?

No on both

[kolaente]

Does it work if you use another provider? (For example GitLab works pretty good)

[ngthwi]

Isn't a button supposed to be displayed on the login page? My issue is that whatever the value of "openid: enabled: " no OpenID button will appear...

[kolaente]

Yes, it will show the button if the provider is properly set up and reachable. The button is shown based on the output from the /info api response. I was asking to see if the problem is on the api side of things (the provider not getting picked up) or in the frontend (the button not being displayed). If Vikunja can't reacht the provider, there should be an error message in the logs.

The auth part of the api response should look something like this:

{
  "auth": {
    "local": {
      "enabled": true
    },
    "openid_connect": {
      "enabled": true,
      "providers": [
        {
          "name": "gitlabcom",
          "key": "gitlabcom",
          "auth_url": "https://gitlab.com/oauth/authorize",
          "logout_url": "",
          "client_id": "xxxxxxx",
          "scope": "openid profile email"
        }
      ]
    }
  }
}

Again, please check if it works with another provider so that we can rule out if Vikunja is the problem. So far, it is not reproducible.

[ngthwi]

Same outcome with GitLab (and I've used a json file this time)...

info: creating the new user vikunja with xxxx:xxxx
usermod: no changes
2024-03-20T11:51:37.556196894+01:00: INFO   ▶ config/InitConfig 001 Using config file: /etc/vikunja/config.json
2024-03-20T11:51:37.702070815+01:00: INFO   ▶ migration/Migrate 05b Ran all migrations successfully.
2024-03-20T11:51:37.702333548+01:00: INFO   ▶ models/RegisterReminderCron 05c Mailer is disabled, not sending reminders per mail
2024-03-20T11:51:37.704144861+01:00: INFO   ▶ models/RegisterOverdueReminderCron 05d Mailer is disabled, not sending overdue per mail
2024-03-20T11:51:37.704386025+01:00: INFO   ▶ cmd/func29 05e Vikunja version v0.23.0
⇨ http server started on [::]:3456
2024-03-20T11:51:56.617089526+01:00: WEB    ▶ xxx.xxx.xxx.xxx  GET 304 /sw.js 849.045µs - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36 Edg/122.0.0.0
2024-03-20T11:51:58.604605242+01:00: WEB    ▶ xxx.xxx.xxx.xxx  GET 200 /api/v1/info 259.822µs - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36 Edg/122.0.0.0

config.json

[kolaente]

The snippet is what the response from /api/v1/info should look like, not a config file.

[ngthwi]

The snippet is what the response from /api/v1/info should look like, not a config file.

Here's the snippet response:

{
    "version": "v0.23.0",
    "frontend_url": "https://***.***.com/",
    "motd": "",
    "link_sharing_enabled": true,
    "max_file_size": "20MB",
    "registration_enabled": true,
    "available_migrators": [
        "vikunja-file",
        "ticktick"
    ],
    "task_attachments_enabled": true,
    "enabled_background_providers": [
        "upload"
    ],
    "totp_enabled": true,
    "legal": {
        "imprint_url": "",
        "privacy_policy_url": ""
    },
    "caldav_enabled": true,
    "auth": {
        "local": {
            "enabled": true
        },
        "openid_connect": {
            "enabled": false,
            "providers": null
        }
    },
    "email_reminders_enabled": true,
    "user_deletion_enabled": true,
    "task_comments_enabled": true,
    "demo_mode_enabled": false,
    "webhooks_enabled": true
}

The json file was the related config.json (a simple copy/paste of the one in your message):

{
  "auth": {
    "local": {
      "enabled": true
    },
    "openid_connect": {
      "enabled": true,
      "providers": [
        {
          "name": "gitlabcom",
          "key": "gitlabcom",
          "auth_url": "https://gitlab.com/oauth/authorize",
          "logout_url": "",
          "client_id": "xxxxxxx",
          "scope": "openid profile email"
        }
      ]
    }
  }
}

[ngthwi]

Are there any verbose/debug modes I can enable?

[kolaente]

You can enable debug logging: https://vikunja.io/docs/config-options/#level

Please check if it works with another openid provider, like gitlab.

[ngthwi]

You can enable debug logging: https://vikunja.io/docs/config-options/#level

Please check if it works with another openid provider, like gitlab.

The issue is not related to a specific provider.... It seems that the OpenID params are ignored and therefore there's no button for OpenID connection.... Not sure if it's a lead but the param name is not consistent:		documententation (config.yml.sample)	Snippet response	The json you provided
Param name	openid	openid_connect	openid_connect

I have tried both but the issue remains.

[kolaente]

Not sure if it's a lead but: the param name is not consistent

That's unrelated. The param does not return the config verbatim. I run multiple installations of Vikunja with openid enabled, I can confidently say the feature works in general. Hence I suspect the openid provider you configured to be the problem.

Might also be a yaml issue wrt spacing or tabs.

[ngthwi]

Tried with a json file as well...

openid:
     enabled: true

This should at least trigger the display of the openid connect button no matter is set in the following parameters, right?

[kolaente]

Can you share the json file?

[ngthwi]

This is the last json file I tested. config.json (I assumed that I only have to set the parameters that I need to be overriden)

[kolaente]

You need to provide a client id and client secret.

[ngthwi]

I'm afraid I'm failing to understand how you implemented OpenID... What I am expecting is a button that is displayed when openid is set to enable: true in config.yml even if the child params (clientid, clientsecret, etc) are incorrect.

Isn't that how it is in Vikunja?

Therefore why would api/v1/info display enable: false while set to true? How would Vikunja check the OpenID provider without any credentails during startup?

ps: great job on Vikunja, I really can't wait to use it

[kolaente]

It will show the button if you have at least one working openid provider. You must configure a provider to authenticate against, simply enabling openid without a provider won't work.

[ngthwi]

My provider is Keycloak and it works with the other apps I've set up. Here's the client I've set up for Vikunja according to this doc:

My (anonymised) config.json:

{
  "auth": {
    "openid_connect": { #tried with "openid" as well
      "enabled": true,
      "redirecturl": "https://xxx.vikunga.xxxxx/auth/openid/",
      "providers": [
        {
          "name": "Keycloak",
          "key": "keycloak",
          "auth_url": "https://xxx.keycloak.xxxxx/auth/realms/xxxxxxx",
          "logout_url": "https://xxx.keycloak.xxxxx/auth/realms/xxxxxxx/protocol/openid-connect/logout",
          "client_id": "vikunja",
          "client_secret": "mysecretfromkeycloakclientcredentials",
          "scope": "openid profile email"
        }
      ]
    },
    "local": {
      "enabled": true
    }    
  }
}

Still no OpenID connect button... "auth_url" url works fine.

[kolaente]

It should be openid not openid_connect in the config file.

[ngthwi]

Tried both...

[kolaente]

Does it work with yaml? Is the config file picked up by Vikunja? (There should be a log message on start of Vikunja)

[ngthwi]

It's not working either... Here's my anonymised config.yml (had to add the .txt extension for github attached files) config.yml.txt

I've noticed a minor issue (because it's not a regular use case): the app cannot switch from config.yml to config.json (✅) then back to config.yml (🚫)

2024-03-20T17:41:31.652438881+01:00: INFO   ▶ config/InitConfig 001 Using config file: /etc/vikunja/config.json
2024-03-20T17:41:31.652565999+01:00: WARNING    ▶ config/InitConfig 002 While parsing config: unexpected end of JSON input
2024-03-20T17:41:31.652620972+01:00: WARNING    ▶ config/InitConfig 003 Using default config.
2024-03-20T17:41:31.835626625+01:00: INFO   ▶ migration/Migrate 05d Ran all migrations successfully.

So I had to reset the containers and went from scratch.

My config.yml is definitely parsed by the app:

• If I set auth: local: enabled: false: there's no login fields at all
• If I make a syntax error, there's an error log like this

  2024-03-20T14:28:57.716660993+01:00: WARNING    ▶ config/InitConfig 002 While parsing config: invalid character '"' after object key:value pair

Where is located the config file in the container?

[ngthwi]

As far as I can understand the function GetAllProviders() in providers.go , there's no validation of the values of the openid parameters in config.yml (meaning that the values are not checked/validated nor the url tested)... So unless the yaml structure of the auth:openid is not compliant and raise an error during parsing, the openid button should be displayed when auth: openid: enabled: true.

For some reasons (unknown from me), my config.yml seems not compliant... I used the sample from here though...

Can you share one of your config.yml (anonymised) with openid that works on one of your environments or test my config.yml as is?

[ngthwi]

To add a different perspective to my issue: the openid connect button should be displayed even with a dummy configuration compliant with the documentation sample.

In my situation, while my external config.yml is parsed (I can test that auth.local.enabled is showing or not the login button when I set the value to true or false), it seems that the element auth.openid is ignored, resulting in this snippet api/v1/info response and no openid connect button to be displayed:

{
    "version": "v0.23.0",
    "frontend_url": "https://***.***.**/",
    "motd": "",
    "link_sharing_enabled": true,
    "max_file_size": "20MB",
    "registration_enabled": true,
    "available_migrators": [
        "vikunja-file",
        "ticktick"
    ],
    "task_attachments_enabled": true,
    "enabled_background_providers": [
        "upload"
    ],
    "totp_enabled": true,
    "legal": {
        "imprint_url": "",
        "privacy_policy_url": ""
    },
    "caldav_enabled": true,
    "auth": {
        "local": {
            "enabled": true
        },
        "openid_connect": {
            "enabled": false,
            "providers": null
        }
    },
    "email_reminders_enabled": true,
    "user_deletion_enabled": true,
    "task_comments_enabled": true,
    "demo_mode_enabled": false,
    "webhooks_enabled": true
}

[ngthwi]

I finally got OpenID connect to work on another test server/docker/oidc server. As you pointed it, if vikunja cannot validate authurl:, the button doesn't show.

Maybe an error log related to this case would be helpful.

Thx a lot for your time.

[kolaente]

Where is located the config file in the container?

It's where you mount it, there's no config file that ships directly with the container.

I finally got OpenID connect to work on another test server/docker/oidc server. As you pointed it, if vikunja cannot validate authurl:, the button doesn't show.

Glad you got it working!

The problem here is, when the config is invalid, it looks like the required config keys are not present, there's no way for Vikunja to know about it.