[beeboobaa3]

Each user gets a token associated with them. On each request you first check if they are authenticated via your auth of choice. If so, you take the token associated with this auth from your database. If not, you take the token sent via cookie. If no token is available, you generate one and set it.

Then when a user "signs up" you do the same thing. If they sent a token via cookie, you associate this token with their auth in your database. If they somehow didn't have a token yet they were probably blocking cookies, but you can just generate a new one at that point.

If a user logs in again later while they already had a token you can choose to migrate all data from that token to their login token, so no data that was created prior to login gets lost.

The point is that there's essentially no difference between regular profiles and shadow profiles. Both are just profiles. And a profile can be authenticated with using its token, or using an associated auth provider.

[namanyayg]

I know this, but do you think all of these parts should need to be coded by hand? It's just a complete waste of time. That's what I meant by writing hacky and ugly code to achieve this.

Plus, in Next, there was no way to associate a token to a social login during the new login in the backend. The only way is to do it via a separate request in the frontend and then relogin the user.

[beeboobaa3]

I mean in total it's like 10-30 lines of code put in the place where you load the user session, and a very small rearchitecture of the database.

So... Kind of, yeah.