Vikunja only requests openid scope when authenticating with Authentik #966

Open
opened 3 months ago by birdcolour · 6 comments

Hi there,

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>
Hi there, 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 https://kolaente.dev/vikunja/api/issues/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](https://kolaente.dev/vikunja/api/src/branch/main/pkg/modules/auth/openid/providers.go#L150), 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> ```
konrad added the
kind/bug
label 3 months ago
Owner

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)

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)
Poster

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 email or profile.

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 `email` or `profile`.

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):

https://kolaente.dev/vikunja/frontend/src/tag/v0.18.1/src/helpers/redirectToProvider.ts#L12

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): https://kolaente.dev/vikunja/frontend/src/tag/v0.18.1/src/helpers/redirectToProvider.ts#L12

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:

https://kolaente.dev/vikunja/frontend/src/tag/v0.17.0/src/views/user/Login.vue#L182

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: https://kolaente.dev/vikunja/frontend/src/tag/v0.17.0/src/views/user/Login.vue#L182
Owner

@LordGaav Can you reproduce that with a private window?

@LordGaav Can you reproduce that with a private window?

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 index.3c6ccad3.js.

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;.

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 `index.3c6ccad3.js`. 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;`.
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.