Vikunja only requests openid scope when authenticating with Authentik #966

New Issue

birdcolour · 2021-09-04T16:20:33Z

birdcolour commented

2021-09-04 16:20:33 +00:00

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 vikunja/api#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 2021-09-04 20:32:07 +00:00

konrad commented

2021-09-04 20:33:22 +00:00

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)

birdcolour commented

2021-09-07 22:13:25 +00:00

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

LordGaav commented

2021-11-06 23:10:03 +00:00

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

LordGaav commented

2021-11-08 10:08:59 +00:00

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

konrad commented

2021-11-09 18:06:14 +00:00

@LordGaav Can you reproduce that with a private window?

LordGaav commented

2021-11-09 18:38:55 +00:00

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

2021-11-09_19-19.png

81 KiB

2021-11-09_19-40.png

71 KiB

LordGaav referenced this issue from vikunja/frontend

2021-11-09 18:45:18 +00:00

Properly return 404 when the file does not exist #966

konrad commented

2021-12-12 11:56:14 +00:00

I was not able to reproduce this with the latest unstable and Authentik set up following this guide.

@LordGaav Can you reproduce it with Vikunja's latest unstable version?

I was not able to reproduce this with the latest unstable and Authentik set up following [this guide](https://goauthentik.io/integrations/services/vikunja/index). @LordGaav Can you reproduce it with Vikunja's latest unstable version?

LordGaav commented

2021-12-15 10:52:30 +00:00

It was really only an issue going from 0.17 to 0.18.x for me, because OIDC was broken in 0.17. The fix you applied in vikunja/frontend#966 also fixes the underlying issue of serving the JS files directly using Nginx.

It was really only an issue going from 0.17 to 0.18.x for me, because OIDC was broken in 0.17. The fix you applied in https://kolaente.dev/vikunja/frontend/pulls/966 also fixes the underlying issue of serving the JS files directly using Nginx.

konrad commented

2021-12-15 12:10:08 +00:00

@LordGaav so this is resolved?