How to get from a JWT payload to registration.data?

damien

Each of the applications that I intend to create registrations for already have their own identifiers. I suspect this is very common.

After authenticating my user, and confirming that they have an active registration to use the target application, I then need to know their corresponding "application account ID".

For example, if my application is "bank account", I need to know which "account number" is owned by user@example.com

From the docs, my understanding is that the expected/recommended way to handle this is to store the account number in registration.data like:

{
  "account number": 12345
}

And maybe I also declare that they're a primary account owner via roles.

I saw in the docs that a JWT includes roles within its payload, so I can easily find out that my user@example.com is a primary account owner of my "bank account" application - but what is the recommended way to discover that they own "account number 12345" ?

Do I literally need to resort to the registration API?

dan

@damien You shouldn't need to resort to the registration API. Instead, I'd suggest using a JWT populate lambda.

This is a JS function that you create then assign to your application.

function populate(jwt, user, registration) {
  // Lambda code goes here
}

jwt is the access token and is mutable. user and registration are the respective objects.

So your lambda might look like this:

function populate(jwt, user, registration) {
  jwt.account_num = registration.data["account number"];
}

More docs here: https://fusionauth.io/docs/v1/tech/lambdas/jwt-populate

2 things to be aware of.

Things will be easier if you don't put spaces into your data field key names.
Putting a bank account number into a token is something I'd think long and carefully about. Tokens offer integrity (you can't tweak token contents without it becoming invalid) but not secrecy (anyone who gets the token can read the contents). Maybe this was just an example, but wanted to call that out.

janettabloomquist

@damien said in How to get from a JWT payload to registration.data?:

Each of the applications that I intend to create registrations for already have their own identifiers. I suspect this is very common.

After authenticating my user, and confirming that they have an active registration to use the target application, I then need to know their corresponding "application account ID".

For example, if my application is "bank account", I need to know which "account number" is owned by user@example.com

From the docs, my understanding is that the expected/recommended way to handle this is to store the account number in registration.data like:
{
  "account number": 12345
}
And maybe I also declare that they're a primary account owner via roles.

I saw in the docs that a JWT includes roles within its payload, so I can easily find out that my user@example.com is a primary account owner of my "bank account" application - but what is the recommended way to discover that they own "account number 12345" ?

Do I literally need to resort to the registration API?

Yes, if you need to retrieve the specific "account number" associated with a user's registration for your application, you would need to use the registration API to fetch the registration data that includes the account number. You could then parse the JSON data to extract the account number.
It is recommended to store the account number in the registration.data field, as you mentioned in your question. This way, when you fetch the registration data using the registration API, you can easily access the account number associated with that registration.
Alternatively, you could consider including the account number as a claim in the JWT payload when the user logs in, along with their roles. This would eliminate the need to fetch the registration data separately. However, you should be careful about including sensitive information in the JWT payload, as it could potentially be intercepted or tampered with. It is generally recommended to keep the JWT payload as lightweight as possible and only include the necessary information for authorization purposes.