[keycloak-user] Using custom client authenticator for clients created through OpenID Dynamic Client registration

[Peter Flintholm Sørensen]

Hi,

I would like to create clients using the OpenID dynamic client registration, and I would like these clients to limit the number of wrong 'client_secret' authentiation attempts. 

For this purpose, I have implemented my own "revoking" ClientAuthenticator that disables the client after 3 wrong client_secret attempts.

Now the problem is how to configure this authenticator correctly in KeyCloak. 

First i tried to deploy the authenticator and create a new authentication flow based on the built-in "Clients" flow. In this new flow, I set the authenticator to my own authenticator. I then defined the realm authentication flow binding for clients to this new flow.

This almost works. My authenticator is invoked on newly created clients, but unfortunately the ClientAuthenticationFlow.processFlow() fails since the provider_id of the new clients is still expected to be "client-secret" (and I set the provider_id to "revoking-client-secret").

If I manually change the authenticator for the newly created clients (using the admin UI) to my own authenticator, it works perfectly fine. But I need this client to work without manual configuration.

I have also tried to change my authenticator provider_id to "client-secret". This makes it in effect overwrite the built-in client authenticator *everywhere* which i don't want.

It seems to me that KeyCloak only partially adopts the client authentication flow defined in the realm authentication binding when creating new clients. 

I hope someone can help - or perhaps lead me in another direction. Please aks if more information is needed!

Best regards,
Peter

(A little background information: The reason i would like to create these clients with limited number of client_secret guesses, is to use them as a sort of online PIN code authentification from a mobile app. The flow I would like is 
1. User logs in 
2. The app creates a client specifically for this installation of the app (authenticating with the users AT).
3. The user select a PIN code which is used to derive a key to encrypt the client_secret for this client. The encrypted client_secret is stored in the app.
4. The app reuses the session to log in through the new client, and gets a long-lived RT.
5. When the user wants to start the app again, the user enters the PIN code, derives the key and decrypts the client_secret. The app calls the token endpoint to get AT from the RT. 
It is of course important that the number of PIN guesses is limited online. Hence the need to revoked the client after a number of wrong client_secret guesses.)