Yes, I am wondering about have the settings of Secret expiration and Rotated secret expiration can be configured as client policy executor rather than realm-wide switches?

Using client policies can mean that different clients in the realm can have different settings (EG. client secret rotation is disabled for some clients and enabled for different clients).

Yeah, I like that. Let's not have a realm level config, and just make this a client policies thing.

Thank you all, think I got it now after looking at the structure of client policies.

• A client policy executor will allow to define expiration settings for clients.
• A client profile allows to bundle policy executors
• The client policy defines the clients where client profiles are applied

I was wondering where exactly the border between client policies and client types will be? Looks like they can do similar things…

in case of multiple thousands of clients would it be feasible to have client group policies for that?
is there anything like that in Keycloak?

In addition to the update possibility specified by the standard, a PUT on sub-resource could be supported. With the data from the example at https://datatracker.ietf.org/doc/html/rfc7592#section-2.2 this would look like this:

PUT /register/s6BhdRkqt3/secret HTTP/1.1
 Accept: text/plain; charset=UTF-8
 Host: server.example.com
 Authorization: Bearer reg-23410913-abewfq.123483

 cf136dc3c1fc93f31185e5885805d 

It's also a pattern which could help at other places where GET/PUT is needed to retain all data in case of an update (e.g. user attributes, realm attributes)

Well, currently we return client secret from GET requests. I don't see any issues with that as both client registration [1] and client management [2] supports returning client secrets and contain examples with client_secret as returned field.

With client secret hashing enabled, we will need to skip returning secrets. But as I mentioned, I don't have any better proposal for the case when hashing is enabled...

In fact, enabled hashing means, that administrator with rights to read-client won't be ever able to read the client secret. Secret will be visible only to administrators with manage-client rights as it is returned only from POST/PUT requests. I see it as a feature and increased security.

[1] https://openid.net/specs/openid-connect-registration-1_0.html#ReadRequest
[2] https://datatracker.ietf.org/doc/html/rfc7592#section-2.1

In addition to the update possibility specified by the standard, a PUT on sub-resource could be supported. With the data from the example at https://datatracker.ietf.org/doc/html/rfc7592#section-2.2 this would look like this:

This sub-resource PUT approach is maybe something to consider for the new Keycloak admin REST API. In this particular case, it likely won't help much as OIDC/OAuth2 specifications prescribes how the CRUD requests look like and there is not sub-resource approach supported AFAIK

I assume there aren't many vendors anyway who make use of the RFC7592 for client management but rather many operated setup where a team needs to implement a manual or automated process for setting a new secret. An additional endpoint will not break standard compatibility and it would be usable for to set a new secret in a convenient way.
I agree that it should match with patterns for a new Keycloak admin REST API, that's why I mentioned that other resources could provide a similar way for update.

Yeah, I see. However in cases when people does not need to be OIDC specs compliant, it is likely better idea for them to use Admin REST API directly? AFAIK the new admin REST API plans to have something like your idea for sub-resources. Regarding old admin REST API, it already has an endpoint for update only client secret. This is the endpoint, which is currently used by admin console when you go to Client -> tab Credentials and you click Re-generate secret .

My original point was related to those cases when people needs to be OIDC specs compliant and hence need to use endpoints described in the specification.

I mean, the current approach would even be more than acceptable if we had the option to never expire the current (new) secret.

created pull request client-secret-rotation, allowing no expiration for new secret #12937

Hey @ramalalc, I completely understand your position. To be honest, I know of cases where this functionality has been used in a production environment for some time without any issues. Community engagement is necessary to validate and provide sufficient data for the project maintainers to prioritize this feature. Unfortunately, there aren't many professionals available, and you can imagine the large number of requests and features that are gaining priority. The "preview" label doesn't necessarily mean the functionality can't be used. I recommend testing and validating it in your environment, and if it proves useful, then use this functionality. Unless you are a user of the enterprise version, in which case you will not receive support from the manufacturer while the feature is in preview.