5:57 a.m.
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.)