JWT token is "invalid signature"?

Get Help
,
18

Ah! I think I see where the confusion lies! Let me see if I can clarify :sunglasses:

Firstly I’d recommend reframing your perspective. Previously in the thread (see here for details) I mentioned that Auth0 typically generates two types of token: an ID Token and an Access Token; the former intended for use by an application, the latter intended for use by an API (a.k.a. resource server). They are both JWTs! Context then becomes an important clarifier when one simply refers to “a JWT” - because one has to understand/convey the use for which said JWT is intended. Thinking/communicating in terms of ID Token and Access Token on the other hand implicitly provides better clarity by virtue of nomenclature :slight_smile:

With this in mind, if we revisit the aforementioned code then - together with the Auth0 Docs for Actions Triggers: post-login - Event Object and Actions Triggers: post-login - API Object - we could perhaps refactor in the following manner:

 exports.onExecutePostLogin = async (event, api) => {
  const namespace = 'https://my-app.example.com';
  if (event.authorization)
    api.idToken.setCustomClaim(`user_meta`, event.user.user_metadata);
    api.accessToken.setCustomClaim(`user_meta`, event.user.user_metadata);
};

The original line (namelyapi.idToken.setCustomClaim) adds a custom claim to the ID Token which the application can use - i.e. to perhaps correctly format the UX. And the new line (namely api.accessToken.setCustomClaim) adds a custom claim to the Access Token which the API can then use - e.g. to perform any ‘fine grained’ authorization, or the like. Both are a, and in this case the same, custom claim added to a JWT!

Some best practice recommendations (and in no particular order):

  1. Prefer to create name-spaced custom claims (see here for further details). This is what the namespace constant declared is intended for, and one would simply use it like so: api.idToken.setCustomClaim(namespace+/user_meta, event.user.user_metadata);

  2. As per my previous post here: prefer to use user.app_metadata (rather than user.user_metadata) to store information that’s not intended for the user, themselves, to modify. You can read about this more in our Actions Triggers: post-login - Event Object docs where event.user is discussed.

  3. Avoid adding any custom claim based on user.app_metadata en masse. It’s highly unlikely to be the intent for any new attribute added to app_metadata that may be added in the future to automatically be exposed as a custom claim! Prefer instead to create one, or more, custom claim(s), each based on a specific app_metadata attribute.

We’ve covered a number of different things in this thread. Consequently, somewhat meandering from the original topic of discussion. Generally speaking, to facilitate more focused and clear conversation I’m going to recommend we now let this thread close; please feel free to reach out here in Community for additional help, and myself and the team will be happy to provide you with specific feedback and advice on a topic by topic basis :hugs:

2 Likes