OIDC: map login to existing user?

Support
1

Hi,

with your help, I was just able to get OIDC running for my freshly installed instance. Thanks again!

When I then logged in via my Keycloak provider, I noticed that my Keycloak identity was not mapped to my existing Vikunja account. They share the same email address.

Is there a way to map a Keycloak identity to existing Vikunja accounts? If not, I would propose this as a feature.

Thanks!

2

Hi again,

this is currently not implemented, so what you’re seeing is expected behaviour. There’s no built-in way to map an existing identity to OIDC.

What would be the expected behaviour in your opinion for these cases?

  • A user logs in via OIDC with an E-Mail address that already exists. Should the account be merged automatically or only after user consent? Should the accounts be somehow linked (still allowing local account) or converted?
  • Vikunja supports multiple OIDC providers. What should be the behaviour if a mail exists in two providers?

Technically, Vikunja isn’t using the mail address to identify the user when logging via OIDC; rather its the combination of the sub (subject) claim which is guaranteed to be unique per identity provider and the issuer.

3

The approach I, personally, like the most and find the most useful is that the accounts are automatically linked or merged in a way to allow me to login to the same account locally and via OIDC.

Linking/merging could also happen when the email exists in multiple OIDC provider logins.

An email address should be unique enough to safeguard that it is the same user.

4

Understood. IMHO this wouldn’t be possible without a major refactor, but I’m far from fully understanding the codebase. Out of curiosity, what is the use case for you?

We’re also using a SSO / Keycloak setup in our org, and even have disabled local account creation altogether. What’s the use case behind supporting both?

5

I just like to be able to access my data even if my SSO provider is offline (I guess that doesn’t happen all that often but I feel safer this way).

I am just a hobbyist self hoster and sometimes one or the other service goes down for whatever reason. And, as murphy’s law predicts, this happens mostly when I am not able to repair it right away (i.e. away from home). And if this happens to my Keycloak instance and I need to access data that is accessible only after logging in via Keycloak, that would be… .

6

Alright, got you. Ultimately that’s for @kolaente to decide. IMHO this seems a bit like a niche use case though and it would be hard to justify bigger refactors to support it.

I’ve also not come across another implementation that allows fallback login with the same user account once SSO is enabled for it. If you think about it from a security perspective, it defeats the purpose of having SSO in the first place.

1 Like
7

I see where you are coming from. Nevertheless, allow me to give just a few examples where you can (and where I do) have both a local and an SSO login: Nextcloud, Rocketchat, Wekan, Gitlab, Synapse. So it is not that uncommon.

For me, SSO login is not so much about security as it is about convenience. Therefore, I don’t see it as a decrease in security (especially, if one can protect the local login with a second factor).

But for the moment, it is enough for me to know that I can’t have a local and an SSO login for the same account in Vikunja. So for the time being, I will experiment with Vikunja using the SSO login but I won’t migrate my wife to Vikunja just yet (because if she weren’t able to access her lists and I can’t fix this right away, her acceptance of my self hosting all of our apps would be gone…). Which is a shame, because it is Vikunja’s migration feature that had me hoping that I could move her away from MS Todo.

Maybe in the future.