Vikunja only requests openid scope when authenticating with Authentik
Love the app, it's exactly what I've been looking for!
I noted that there was some discussion about not getting Authentik working with Vikunja in #864, and I thought it would be useful to at least collate some of this info together in one place, as I've just tried to get this working myself - with some help from the Authentik discord too!
It seems that, despite the correct scopes
openid profile email being hard-coded, the only scope ever issued in any of these requests is
openid; the workaround mentioned in the other issue (disable and re-enable scopes in Authentik) did not work for me. This causes Authentik to only include this scope in its response, and thus when authentik redirects back to Vikunja, the missing email and profile prevent a successful login only when that user has never logged in before.
I was able to work around this issue by capturing the request Vikunja issues to Authentik with chrome dev tools and manually editing it so that the query string contains the correct scopes (
scope=openid%20profile%20email) which allowed the login and subsequent user creation to complete successfully. Now that that user exists, it is sufficient to log in thereafter only using the openid scope. This is a fine workaround for me, with a small number of users, but obviously isn't the best option!
More than happy to help with debugging this! I'm running the latest version of each service with the k8s at home charts (vikunja-4.1.0, appVersion 0.17.1; authentik-2.2.1, appVersion 2021.8.4) and my config.yml looks like this:
log: level: debug database: type: sqlite auth: local: enabled: false openid: enabled: true redirecturl: https://vikunja.domain.com/auth/openid/ providers: - name: vikunja authurl: https://authentik.domain.com/application/o/vikunja/ clientid: <clientid> clientsecret: <clientsecret>
Wow thanks for that in-depth issue!
Would you be able to check if that's still an issue with the latest unstable build? (
latest tag for the docker images)
With the latest image, there's a slighty more descriptive error in the UI of "No email address available. Please make sure the openid provider publicly provides an email address for your account."
Looking at the requests issued, the underlying issue still seems to be the same - the scope in each request is still only
openid; no sign of
Can confirm that this issue happens with 0.18.1, with the same "No email address available. Please make sure the openid provider publicly provides an email address for your account." message. My config is an almost exact copy of @birdcolour .
Apart from the API not including the scopes, what's ever weirder is that the Frontend also hard codes the required scopes, and also doesn't seem to properly pass them to Authentik (this code is also present on main):
Ok, it gets weirder. This morning I tried to login from my work PC with Firefox 94 on Ubuntu 21.10, and it just worked. Checking the Network logs also shows that the right scopes get passed.
The only thing that I can think of is that this browser never openened Vikunja before, and my other non-working browser has, and the first version that browser openen was 0.17.0. Maybe there's a Service Worker that doesn't get properly reloaded so old code gets run or something? Because 0.17.0 certainly did send the wrong scopes:
I can reproduce it on my main PC with Firefox 94 on Ubuntu 20.04. When I 'just' opened Vikunja, it shows me that frontend 0.18.1 is loaded from the service worker. After clicking login, I get the error (Attachment 1).
When I unregister the service worker and clear all cache, on the next load it shows frontend version 0.17 and the service worker registering itself again (Attachment 2).
When I disable cache in the Network tab, and refresh the page, I automatically get redirect to Authentik (something that 0.17 didn't seem to do for me), and I can login fine. Console shows frontend version 0.18.1 and service worker.
After that, I haven't been able to reproduce it. A private window immediately redirects to Authentik with the proper scopes and shows the right frontend version. A look in the Docker image shows that only the right frontend version exists on disk
It might be worth looking into the settings of the Vikunja service worker, and find a way that it's less aggressive in local caching the application. It might also have something to do with the Nginx config in the frontend Docker, because it always returns a 200 OK status with a properly set cache header, even on files that don't exist. This is certain to confuse browser cache / service workers (see https://github.com/go-vikunja/frontend/blob/v0.18.1/nginx.conf#L74). I don't see why it's not just
try_files $uri $uri/ =404;.
Deleting a branch is permanent. It CANNOT be undone. Continue?