Multiple providers per user?

[ciscoheat]

A common feature with OAuth is to connect multiple providers to the same user, or at least one extra, an email provider as fallback. From what I see there is a 1:1-relation between user and provider however. Did I miss something, or do I have to make a "RealUser" entity that has an 1:n relation with user, to make this work?

[pilcrowonpaper]

If the OAuth provider account shares an email with another, you can use googleOrGithub (for example) as the provider and use the user's email as the identifier. If they don't though, you'd need to have something that has n:1 relation with the user. .

I'd like to change the provider_id column to a list/array, but that would limit the database that could be used. Making an account table could work but I'm unsure if that's too specific.

[ciscoheat]

That's true, they will usually be the same, or will at least be in my case, so that works. Thanks!

Solving it in general requires another entity, as you say. I think an account table makes sense, what would be the problems, since the user:session relation is already 1:n?

[pilcrowonpaper]

Implementing will be relatively easy, I think, but it's more about scope. Is this feature necessary? If you don't have multiple connected OAuth providers, it's just going to increase the size and complexity.

[Yiak]

Came here with the same problem. I think an account would work well and make more space for future features compared to a list of provider_id.

[pilcrowonpaper]

We've been discussing about this on Discord and it's much more complicated than just having an one-to-many relations between user and provider/account table. One big issue is preventing users from removing the original provider, making that work in a relational database.

Migration is something that needs to be handled as well, since we're moving the provider_id column to its own table. That said, it'a relatively simple migration so I'm open to implementing it.