How to include my own Database unique identifier in a JWT / new account that is created?

Help
, ,
1

Hi :slight_smile:

So I’m experimenting using Auth0 with a:

  • Front end SPA website (e.g. React or Angular2) + something simple like ‘Lock’.
  • Backend API in .NET or .NET Core (but again, could be anything).

When I play around with the Auth0 React Sample it easily logs me in and logs out. Great! If the user didn’t exist, then it creates a new user i the Auth0 ‘database’ (for my account).

Now - I’m wondering if the following is possible:

  • Goto website. User not logged in.
  • Click ‘sign in/create account’
  • Sign in/Create new account modal is displayed (i.e. Lock modal). Offers Google/FB/u+p options.
  • I click GOOGLE
  • I do the Google-Auth-Dance.
  • At some point, I now need to return from Google to … somewhere-in-my-app.
  • I now attempt to create a new account in my database. E.g. POST /accounts/
  • This returns some GUID which is like a unique Id for my user.
  • Auth0 now gets told about this, stores this in the Auth0-DB (maybe app_metadata ??)
  • The JWT token is now returned to the browser and includes this new GUID in it

Now - each call the React app makes to the backend API will include the Bearer <token> header, which includes the GUID and voila! I can map/cache my private user data to the current request and “do whatever”.

I was wondering if this might be possible somehow with some server-side trickery? Maybe something like …

  • Login/create account with Lock
  • Once ‘done’ I now have a JWT with some unique id for my Auth0 user.
  • I async call my backend API and create a new user. This can (optionally) hit the Auth0 api (server->server communications using an access_token?) to pull down some profile info, like Name, etc. I store this in my DB.
  • Any new request to the API will include the standard Bearer <token> header which includes this uniqueId … so I can then check that in my DB/cache and use whatever data I need.

I feel like this might be a weird solution … but defeats the purpose of what JWT’s are … like, JWT should have enough information already for me so I don’t need to keep hitting a DB or cache. It is the cached item! But I just don’t see how I can handle things like user-permissions (and these might change … e.g. promoting a user or demoting).

So - anyone have any suggestions / corrections to my understanding of things?

2

This can be achieved using Rules and app_metadata. You can setup a Rule to create a new account in your database (POST /accounts/), and store the returned GUID in app_metadata. You can then add this custom claim to your JWT in the Rule:

const namespace = 'https://myapp.example.com/';
context.idToken[namespace + 'my_new_guid'] = user.app_metadata.my_new_guid;

The JWT returned to your application will now have the my_new_guid claim to use as you like.

3

Wow! interesting :slight_smile: Ok. so I found this sample rule: https://github.com/auth0/rules/blob/master/rules/aspnet-webapi.md . Great!