First of all: thanks for Auth0! I’m new to it and using it has been fantastic.
I presently puzzling together what the best way to plug Auth0 into my new application should be. I’ve been busily reading the docs for some time and I think I have an idea of how things are supposed to hang together. I wanted to express them here in the hope that you could say “yup, that’s the way to do it” or “no, no, no, STOP!”
Here’s my setup:
-
Client app is a React SPA which will use Lock to obtain an access token from Auth0.
-
It will talk to an ASP.NET Core application to obtain data, customised for the authenticated user using the access token.
What this means is, I need to be able to identify a user from an access_token
. I’ve learned from reading the docs that passing an id_token
is not the done thing. So that’s cool. The question is: how do I identify which user I have from the access_token
?
I understand from the docs that it’s possible to take an AccessToken and get profile data by making a call to Auth0 and passing the token along; like so:
var domain = _config"Auth0:Domain"];
var apiClient = new AuthenticationApiClient(domain);
var userInfo = await apiClient.GetUserInfoAsync(accessToken);
Now that’s great; but naturally I don’t want to call Auth0 on each API call. Looking at the Claims my ASP.NET Core app receives when the access token is passed I can see that we get a sub
claim (also called http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier ). This includes a value that looks like this: auth0|1234567890andon
. Questions that arise:
- Does
sub
uniquely identify a user? My guess is “yes”. (This seems to suggest that is so: Scopes ) - Is
sub
a reliable way of identifying a user in the long term? Does a user have a singlesub
which is assigned to their email address? Again, my guess is “yes”. - Does that
sub
remain the same forever? Can a user’ssub
ever change? I’m hoping the answer is “the sub remains the same forever”. My assumption would be that if I’mauth0|1234567890andon
now then I’mauth0|1234567890andon
always. Is that so?
Assuming the answers above are as hoped, I would think that specific user data could be uniquely keyed against the sub
property in my database. If my app needs more information about a sub
then it could use the access token (which sits alongside the sub
in my claims) to call the apiClient.GetUserInfoAsync(accessToken)
.
Further, if I decide that I want to use a different user id in my database, as long as I maintain a table that maps sub
to my own user id, I guess I’m good to go?
Does this all seem reasonable? Thanks again!
To see my approach in practice see this repo: GitHub - johnnyreilly/auth0-react-typescript-asp-net-core: A boilerplate illustrating Auth0 usage with a React / TypeScript client and an ASP.Net Server
I blogged about it here: Auth0, TypeScript and ASP.NET Core | johnnyreilly
Happy to correct any mistakes so I don’t spread bad information.
This was a similar question which I found useful:
http://community.auth0.com/questions/6761/get-user-data-server-side?childToView=6795#answer-6795