Custom fields / user data

[FlxMgdnz]

It could be beneficial if Hanko would allow storing additional user data. This could make another user table unnecessary for certain use cases and thus speed up app development with Hanko even more.

First ideas for custom fields that came up were:

• Name (e.g. for email personalization)
• Marketing consent
• Phone number
• Foreign IDs (e.g. Stripe)
• Age
• Address

Setting this up per Hanko instance would require some form of definition of supported data fields and ways to add the desired fields to the config. The Hanko backend data model would have to be upgraded accordingly to be able to handle this "dynamic" data per user.

Additionally, but not necessarily, it may be desired to show or even require some or all of those fields during onboarding in hanko-auth and allow editing in hanko-profile which means that properties like labels, placeholder texts, and maybe even input validation need to be taken into consideration as well.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[caioluis]

Adding up on Felix idea, some other fields ideas:

• Profile Image
• Custom key=value metadata
• Short bio/description

Perhaps they are out of scope. On the next steps any ideas on how we could start and break this epic down into pieces? I will probably have a look back on this in two weeks from now, if there are no other ideas, I could then draft something.

[plopezlpz]

Also add a map of custom key/values that can be included on the JWT of that user. Currently JWT is not configurable, as per this.

[ghstahl]

Make it generic. All we need is key/values. What those would be are up to me.

Once we do have metadata associated with a user, then something else should be in the product to let a developer use what's there to add to an id_token right before the id_token gets minted.

my particular use case I would have the following metadata.

{
  "real_user_id": "USRBlah1234",
  "integrity_id": "1234567890",
  "some_other_string": "here for the fish"
}

On certain lifecycle points in the signin-in flow custom actions would be called.
In this case I would have my custom (python, javascript, etc) get executed in the pre-id_token-mint stage.

I would then pull only the key/values I want out of what is available and give them to hanko to write as claims. In the end my id_token would have the following claims in addition to all the common jwt ones.

{
  "real_user_id": "USRBlah1234",
  "integrity_id": "1234567890"
}