Any specific reason to ask this? Or just curious?

Auth0 is having issues again. I was complaining to a friend about how we used to be trending towards making auth safer and easier with frameworks, but that as an industry we have shifted towards magical saas solutions that have pretty questionable trade offs. He's starting a company soon and asked me basic things about how auth works, which led me down the path of googling what sort of stuff is out there these days. I didn't know about keycloak until a couple weeks ago when I helped someone understand client certificates and build them for that, so I checked out their documentation a bit more and searched for alternatives and found you guys listed as an alternative.

Ah i see!

Interesting journey!

By questionable trade offs, I like the idea of trusting a third party to be highly available, to be super on top of security and to make best practices easy. When things go into feeling like lock in and rent seeking, that makes me really uncomfortable because it sets up for a long term relationship with an unhealthy power dynamic.

Yea! Makes sense. That problem is actually one of the big reasons for us creating SuperTokens in the first palce.

That's good to hear. Are you considering (or do you have) an opinionated way for people to store their concept of a user in their app? There are way too many places out there that think using email as a unique key is safe or reasonable.

We issue UUIDs per user that never change (for that user)

You can of course change a user's email too via our API. And each user's email is unique too.

But we use the unique UUID to ID a user post sign in

"And each user's email is unique too." - how to you handle untrustworthy third parties then?

what do you mean?

a@gmail.com signs up with google. We also trust github for auth. Github gets hacked and the attacker logs in as a@gmail.com verified by github

Ah i See. So we don't do automatic account linking for this exact reason

Instead, what we now do is to create separate user IDs for someone who used same same email, but different providers

But we do plan on enhancing that to warn the end user that they are about to create a new account and maybe they meant to sign in with another provider (which they had used to sign up earlier)

okay, cool -- when you said each users' email was unique I read that as linking

Ah no. So for social login, the unique item is not the email, but the social provider's userID + a provider ID (like "google", or "github").

For email password login, the email is unique

adding in group management things would be 🌈 amazing. Like tracking invites to alias@gmail.com that sign up as nonaliased@gmail.com

I'm not sure I understand wgat tracking invites means.

Can you elaborate more please?

admin1 invites a user with an email invitation that has a token in it to "aliasOfperson@gmail.com". The person clicks on the token, and already has a users on the app, under their non-aliased email. It's easy to have a hanging pending invite for admin1 to see. (I've run into a lot of places where the act of inviting someone creates an account that can only be authed to from the invite token, or something similar)

So this would allow someone to be invited via some email, but then actually sign up via another email?

iff they were the same person

Right.

Interesting use case.

When would this desirable though?

Cause every invite system I have seen enforces the use of the same email to sign up that was used to generate the invite in the first place.