It can be quite complicated to create clients in Keycloak as there are a large amount of configuration options available for a client. As an example let's imagine 3 different use-cases for clients:

• SPA
• Resource provider
• Service account (client credential grant)

For all 3 cases to create the client a user needs to know a lot of details on how to configure a client to fit the above use-cases.

Now imagine you created 1000 clients for SPAs and you realised you made a mistake in how you configured them. Or, you simply want all to have some consistent config. The only way to do that would be to go through each client through the Admin Console or REST API, and update/verify the config.

In addition it is rather hard to manage large amount of clients, as there's no way to distinguish which clients fill which use-cases as mentioned above. For example if you want to find all "service accounts" the only way to do that is to iterate over all clients, to identify those that only have service account support enabled, and not configuration that allows other use-cases.

A solution to these problems would come by introducing a concept of client types in Keycloak. A client type would:

• Provide common config configuration (for example a SPA has standard flow enabled, is a public client, etc.)
• Limit what can be configured (for example a SPA can not enable implicit, direct access grant, etc.)

When creating a new client it is possible to select either the generic type, or a specific client type. When creating a client of a specific type the options on how to configure it would be limited.

To define new client types we'd want:

• Some built-in types (SPA, resource provider, etc.)
• Custom Java provider
• Declarative JSON provider

Custom client types can be deployed to the server globally, or declarative types could also be configured for individual realms.

At an implementation level a ClientType would wrap a ClientModel, in order to augment the config and also to validate new clients and updates to clients. A ClientType would also provide metadata to the Admin Console so it can show only relevant configuration options.

Implementation of client types should be split into multiple milestones:

• Milestone 1: Java client types, and JSON deployed to the server globally
• Milestone 2: Admin console to have the ability to select a client type when creating clients, and limit what options are available
• Milestone 3: Per-realm declarative client types. This could potentially not be considered at all.