@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.
