Clients are entities that can request Keycloak to authenticate a user. Most often, clients are applications and services that want to use Keycloak to secure themselves and provide a single sign-on solution. Clients can also be entities that just want to request identity information or an access token so that they can securely invoke other services on the network that Keycloak secures.
Each realm (identified below) might have a different set of client ids.
Client IDs Enumeration
When landing on a login page of a realm, the URL will be auto-filled with the default ‘client_id’ and ‘scope’ parameters, e.g.:
It is possible to identify additional client_id via intruder, by keeping all the other parameters with the same value:
A good list to use for this purpose is: https://github.com/telahdihapus/wordlist-default-username-password-product/blob/master/username_clean.txt
The following, additional, default client ids should also be available upon Keycloak installation:
No HTTP response code could help us to identify a valid client_id from a wrong one. You should focus on the length of the response that is different from the majority of the responses. In my case, I had 1283 responses with a length of 2451 and just 6 with a different length. Those are the valid client IDs
This process should be repeated for each valid realm identified in previous steps.
Clients can be configured with different Access Types:
Bearer-Only – Is used for backend servers and API (requests that already contain a token/secret in the request header)
Public – Able to initiate login flaw (Auth flow to get an access token) and they don’t hold or send any secrets.
Confidential – Used for backend servers and able to initiate login flaw. They can accept or send secrets.
Therefore, when we encounter a “client_secret” parameter in the login request, we’re probably looking at a client with a Confidential or Bearer-Only Access Type. Later on in the article, more information about this type of access in the exploitation part.