# Initializing custom user attributes

**URL:** <https://forum.keycloak.org/t/initializing-custom-user-attributes/26240>\
**Category:** Getting advice\
**Created:** [May 27, 2024, 8:25pm UTC](https://forum.keycloak.org/t/initializing-custom-user-attributes/26240 "2024-05-27T20:25:11Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![ctrworthin](https://yyz2.discourse-cdn.com/free1/user_avatar/forum.keycloak.org/ctrworthin/32/10524_2.png) [@ctrworthin](https://forum.keycloak.org/u/ctrworthin)\
**Post date:** [May 27, 2024, 8:25pm UTC](https://forum.keycloak.org/t/initializing-custom-user-attributes/26240/1 "2024-05-27T20:25:11Z")

</div>

Hi,

I’m surprised this isn’t a more common use case, and I’m struggling to figure out the proper way to do this.

We need to initialize some custom user attributes whenever a new user is registered (or is brokered / imported from an external IdP, or any other case where a user is logging in that doesn’t already have these custom attributes set somehow)

These custom attributes:

- Are not intended to be user facing (so presenting a form is not an option)
- Involve generating UUID(s) (so a simple default value is not an option)
- Must be applied prior to generation of their first access token (so that it is available for mapper(s) to add the attribute as a custom access token claim).

There doesn’t seem to be any ‘out of the box’ functionality in Keycloak that we can use to accomplish this, so we’ve conceded that a custom SPI will be necessary.

The trouble we’re having is - of the available types of SPIs we can implement, which is the best to target?

So far we’ve considered:

- As an event listener SPI, listening for `REGISTRATION` events, as suggested here: [Implementing custom user registration with setting default attributes](https://forum.keycloak.org/t/implementing-custom-user-registration-with-setting-default-attributes/22856). It’s unclear though what the OP means in that attributes did not persist properly when set during the `REGISTRATION` event, nor do I understand their proposed workaround.
- As an authenticator SPI, inserted into the ‘first-login’ and / or ‘registration’ flows. I’m ambivalent about this approach, as it’s inline with the registration process, but feels like an inappropriate use of an authenticator, given it has nothing to do with authentication.
- As a custom User Storage SPI. This feels like it’d provide the most comprehensive and reliable control over user provisioning, but at the cost of being a significant endeavor to fully implement.

What of these seems like the best approach? Or is there another that we haven’t considered?

Thanks!