Adding User Data in Access Token for Custom Authorisation

Help
,
1

Is it a good practice to add user information e.g. email as a custom claim in access token? I have two use cases actually:

  1. Find out the user who calls the API. Adding email to access token seems the easier way,
  2. Custom authorisation based on users. In short, this means: get the user based on email in the token. If the data being modified / accessed is created by that user, then he can modify / access the data.

What I really want to know is whether embedding email in token is the better approach? Or should we add email as part of the payload?

2

It sounds acceptable as long as there are sufficient constraints in the system. The issued access token which at this time is a JWT will always have the sub claim containing the user identifier of the end-user within Auth0. However, if your system identifies users by email address then adding the email to the access token is acceptable, but you should have in mind the consequences of doing so. For example, if how you configured your Auth0 service allows for multiple identities to have the same email address then technically multiple user identifiers will now include the same email in the access token which may or may not be what you desire.

In addition, including only the email address in the access token without taking in consideration if the email address of the associated identity has been verified then may also pose some issues. Finally, any information included in the access token will be fixed for the lifetime of the access token so you also need to review if you’re okay with that situation.

In conclusion, adding custom claims to the access token as a way for the resource server to make better informed decisions (including custom fine-grained authorization) it’s acceptable, however, you’ll always have to review the situation on a case by case basis depending on which information you’re including and how you’re using it.

With regards to including the information inside the token versus on the request payload you have to take in consideration that the code including the information within the token can be considered trusted code (it’s running in a server-side environment that only tenant admins have control over) while if you have a client application that runs on the end-user agent then technically the end-user can modify the request payload.