Associate OIDC user with existing user #1589

New Issue

kgehmlich · 2023-08-13T18:31:04Z

kgehmlich commented

2023-08-13 18:31:04 +00:00

Vikunja API version: 0.21.0

Expectation:
When I log in for the first time using OIDC with a user that has the same email address as an existing Vikunja user, I should be logged in as the latter. A new user should not be created.

Actual behaviour:
When logging in for the first time with OIDC, a new user is created with the same email address as my existing (pre-OIDC) user. The new user has a random username.

Relevant info:

Identity provider is Keycloak
Keycloak user has same username and email address as existing Vikunja user

Vikunja API version: 0.21.0 Expectation: When I log in for the first time using OIDC with a user that has the same email address as an existing Vikunja user, I should be logged in as the latter. A new user should not be created. Actual behaviour: When logging in for the first time with OIDC, a new user is created with the same email address as my existing (pre-OIDC) user. The new user has a random username. Relevant info: * Identity provider is Keycloak * Keycloak user has same username and email address as existing Vikunja user

konrad commented

2023-08-22 16:55:09 +00:00

I think the way it currently works is the correct way to do it. From Vikunja's perspective, the two users are different because they come from different sources. How should it behave if you want to log in using credentials after logging in through the oidc provider?

Do you know other applications doing it the way you described it?

I think the way it currently works is the correct way to do it. From Vikunja's perspective, the two users are different because they come from different sources. How should it behave if you want to log in using credentials after logging in through the oidc provider? Do you know other applications doing it the way you described it?

kgehmlich commented

2023-08-22 20:03:30 +00:00

Hmm, that's a good question, maybe my expectations are wrong.

I've seen some services - WikiJS is an example - work this way. If the unique identifier for the user (email, in WikiJS) matches the identifier provided by the OIDC provider, then both login paths authenticate as the same user. However, I'm just now realizing that that seems like a pretty major security flaw, since a bad actor could gain access to an account that's not theirs just by setting the right email address in the OIDC provider.

Another approach I've seen is one where the service offers to link an existing account to the new login (I think I saw this on Gitea, actually), but that could easily be a lot of work to implement and might not be worth the effort.

Hmm, that's a good question, maybe my expectations are wrong. I've seen some services - WikiJS is an example - work this way. If the unique identifier for the user (email, in WikiJS) matches the identifier provided by the OIDC provider, then both login paths authenticate as the same user. However, I'm just now realizing that that seems like a pretty major security flaw, since a bad actor could gain access to an account that's not theirs just by setting the right email address in the OIDC provider. Another approach I've seen is one where the service offers to link an existing account to the new login (I think I saw this on Gitea, actually), but that could easily be a lot of work to implement and might not be worth the effort.

konrad commented

2023-08-23 06:39:41 +00:00

However, I'm just now realizing that that seems like a pretty major security flaw, since a bad actor could gain access to an account that's not theirs just by setting the right email address in the OIDC provider.

That's probably why very few services do this.

Another approach I've seen is one where the service offers to link an existing account to the new login (I think I saw this on Gitea, actually), but that could easily be a lot of work to implement and might not be worth the effort.

We might build that at some point, but not anytime soon.

I'll close this issue now as the original problem does not seem relevant now. Feel free to open a new one for merging accounts.

> However, I'm just now realizing that that seems like a pretty major security flaw, since a bad actor could gain access to an account that's not theirs just by setting the right email address in the OIDC provider. That's probably why very few services do this. > Another approach I've seen is one where the service offers to link an existing account to the new login (I think I saw this on Gitea, actually), but that could easily be a lot of work to implement and might not be worth the effort. We might build that at some point, but not anytime soon. I'll close this issue now as the original problem does not seem relevant now. Feel free to open a new one for merging accounts.

konrad closed this issue

2023-08-23 06:39:41 +00:00

konrad referenced this issue

2023-08-26 09:13:13 +00:00

Duplicate users after changing oidc provider #1596

konrad referenced this issue from a commit

2024-02-07 14:00:32 +00:00

chore(deps): update dependency netlify-cli to v8.19.3 (#1589)

Sign in to join this conversation.