Client attributes are not currently meant to store arbitrary data about users. Hence why these are not exposed on the admin console. Adding this tab may confuse most users as such I'm not really in favour of adding it. Can you please expand on your use-case? Can it be achieved with having client themes instead?

I would suggest opening a discussion around this on the dev mailing list. The previous issue/PR was rejected as this is not something we really want to add, so we need to have a discussion around this.

Sorry for the late reply ,
well here is an example of how we're using the client attributes,

there some stuff that we can accomplish using themes but some not like for example : no_email_verification : in some clients we don't want to send email verification during registration
auto_group_join : we would like to join user to certain groups during login 1 or more ...
...

please let me know if you need any other clarifications

thanks

I don't see much interest in this PR or the associated JIRA, and I'm not convinced this is something we should add. Can you please start a discussion on the dev mailing list to see what others think and if there are others in the community also interested in this?

One use-case I've encountered in support of adding this.

We have developed some custom authenticators that have the following requirements:

• should only run in login flows for specific clients
• need additional arbitrary metadata scoped to each client (e.g. client A's property businessId needs value B123, client B's property businessId needs value B456)
• the Authenticator's requiresUser is true, as we also need the UUID of the user

All of this info is used as parameters to an external API which returns certain information that we then map into tokens.

We don't allow local users (every user needs to be brokered with an external IDP), so we currently have this authenticator configured in a custom post-broker-login flow. To achieve the listed requirements, we have to create a pretty hacky authenticator configuration that is essentially a string representation of a serialized json object to associate these values together e.g.

{
    "clientA": {
        "businessId": "B123",
        "foo": "bar"
    },
    "clientB": {
        "businessId": "B456",
        "foo": "bar2"
    }
}

The downside of doing this is also that we need to mark the authenticator to always run, and then write logic in authenticate to check this configuration to see if it should actually execute or perform a no-op.

I wanted to use client attributes for this use-case, so in the authenticator's configuredFor, method, I could read an attribute from the client to check if it actually needs to run. I would also use client attributes to populate the businessId property per-client.

Adding client attributes to the admin ui makes management of this configuration a lot easier.

We wan't to activate / deactivate some feature on the theme for some clients, how would you do it without custom client attributes ?

One more usecase.

User has attributes, that may be added to claim by User Attribute mapper.
Client is also a subject of authentication when client_credentials used, so client attributes is logical entity to be used for claim mapping.

We are using Keycloak for M2M between our microservices as well as for external clients who use our APIs. How can we configure certain important parameters for some clients if we cannot set up any kind of metadata? I understand that adding attributes (which we can also call metadata) would allow us to extend behavior and, together with Protocol Mapper, add more contextual information within the tokens.

Definitely something that should have been added. We need to make UI decisions by client for UI flows.

Client A might need to only accept certain IDPs, display different error messages / custom redirects or need different steps in the flow. Being able to capture this via client tags quickly in UI, read them in, then modify the behavior would make that a lot easier to deal with for admins.

Also adding my vote for this. Currently, there’s no way to group clients in Keycloak, which makes managing a growing number of clients increasingly difficult. Native grouping support would be a highly valuable feature. Even the ability to add and view custom attributes in the Admin UI would go a long way in helping organize and manage clients more effectively.

We have a similar use case where we need client-specific configuration that determines how certain user attributes are translated to claims for each client.

We have developed a custom protocol mapper for this, which should be able to read this custom client configuration. Generic attributes on the client itself would be a good place to store these.

(Note: these could also be stored on a client's associated service account which has attribute support. However, this excludes public clients which are in scope for this configuration in our case)

Any updates on this? Consider this some community appetite for the feature here in 2026, in addition to the upvotes on the original question and comments above!