Link anonymous user with logged in one

[MrZoidberg]

In my project, I'm using multiple providers - anon, email, telegram. What I want is once user logs in as using proper identity provider, I want to move all data that was created as anon user to a user with valid identity. However, I don't see any way to link those identities.
Is it possible to implement with this package? If yes, what design do you suggest? I can try to create a PR for this.

[umputun]

there is no built-in linking, and I don't think it belongs in the library. Moving data from one user to another is your app's storage, which auth never sees. Everything needed is already public, so this can be done on the app side.

the catch is that a merge done automatically right after login is unsafe. The email confirmation link and the telegram token work from any browser, so an attacker can send his own confirmation link to a user who is in the middle of linking, that browser gets logged into the attacker's account, and the anon data moves there. The merge needs an explicit confirmation.

what I would do:

1. make anon IDs unguessable. With AddDirectProvider the ID is anonymous_ + hash of the name, so anyone typing the same name gets the same ID and could claim its data. Use AddDirectProviderWithUserIDFunc and add a random part to the ID.
2. before redirecting to /auth/<provider>/login, call your own endpoint with POST, behind Middleware().Auth and with the X-XSRF-TOKEN header. It checks the current user is anon, stores a short-lived pending record server-side (nonce, anon ID, what the user is about to log in with, expiration) and sets the nonce in an HttpOnly cookie. Don't try to read the anon token inside the login flow itself: the oauth providers replace the JWT cookie with a handshake token at the start of login.
3. after login, if the request carries the nonce cookie and the pending record is still alive, show "move your anonymous data to ?" and remember the exact user ID shown. Only a confirmation POST (same XSRF header) moves the data, and only when the current user ID still matches the one shown. Do the move and delete the pending record in one DB transaction, so it can't run twice.

on the confirmation screen show something an attacker can't fake. The display name is not enough, for email login it comes straight from the user query param. For email you can bind it in step 2: store the address the user typed and check that the new user ID is "email_" + token.HashID(sha1.New(), address).

the endpoints from steps 2 and 3 should also reject a token passed as ?token= or in the JWT header. The middleware accepts those before the cookie and doesn't check XSRF for them.

[MrZoidberg]

Looks interesting, thanks. I will try to implement this approach and will update with results; it will likely take some time. I think it worth updating the project docs to give directions to anyone willing to do the same.