@jmangelo, I’m having a similar issue that OP is having, and have a hard time getting my head around the opaqueness of the sub field as well.
I am developing a new system where administrators would be creating user accounts for the users (either by invitation, or by actually creating the user, this is TBD). Now in the application DB it would be
What are your recommandations for a new system it would be confortable to key the user accounts by email address, because that how the admins invite people, and that’s what users will use to log in (we’re not planning on using social login at the moment, although that may pop up as a requirement later). It’s also easier to say that use did this or that, rather than user did this or that (although yeah, that is just presentation, but it’s easier to follow when debugging).
When creating the user account specific metadata for the user needs to be created in the application database (permissions, a few resources for the new user, etc). And at this point we have no idea what the opaque value of the sub field will be when the user actually logs in through auth0. [Using the email address as sub would solve this issue], so we can’t key the users table with the auth0 opaque value, although as far as I’m reading your replies, neither should we.
So to the actual question:
What are your recommendation on how to pair up an internally generated user primary key (in this case the email address) to an incoming sub claim? The whole reason for using jwt tokens would be that we can validate them “offline”, without making an additional http request to auth0 for each request. Possibly keep a lookup table from sub -> user id, and only retrieve the email from the userdata endpoint when a new value is encounetered? Or the sub identifiers guaranteed to be stable?
What are the guarantees around these sub fields? Will they change for any reason? What happens when a social login is added for the user? Will the sub field be different based on which login method he used? (user/pass vs social). If the social login contains the same email address, then using the raw email would solve the issue, but that is not always the case.
Is there any good documentation on how auth0 handles multiple logins for the same user?
Now if the sub field should be treated as an opaque value,