I need a more cohesive plan

I "wrapped up" the auth service a bit better today. Kinda of forgot that I would have all day off today.

After getting the auth service converted back to Next.js, getting the whole login-via-email flow working, I'm realizing that I need a more comprehensive plan for what I'm going to build, go figure :P

The auth service currently validates that a user owns a specific email, and I'm pretty sure that people can't replay anything, or craft funky urls that send people to strange places once auth is complete. What I still haven't figured out is how I'm going to take the fact that someone clicked a URL in their email and turn it into an interactive comment box which is attributed to their identity.

I've considered including a token in the query parameters of the "target url" we redirect the user to after authentication is complete, but it feels like a bad idea to put the token in the URL like that.

I've considered putting a one-time code in the URL which JS on the page will immediately use to fetch a token and then store in localStorage, but it feels like a pretty fragile system.

Now I'm thinking I should probably just use the auth service to oauth against, and have the auth service provide nothing but a unique user id which the comment system can use as the key for a user profile. That "login with spalger.dev" is the same as logging in with any other social provider, but of course it wouldn't really be useful for anyone else unless they could completely rebrand "login with spalger.dev" to be their own service/stack/brand.

If I go with this plan I expect that I'll be able to add passkeys via a "auth specific" interface that doesn't have any relationship to the poster profile, manage things like additional social logins, etc. All this would be a part of some auth settings page which would be separate from the commenter profile. But how will we explain that to users who just want to add "Sign-in with Github" or a "passkey" to their existing profile?