- Should the keycloak-client's access type be public or confidential?
From the RFC 6749 OAuth 2.0 specification one can read:
confidential
Clients capable of maintaining the confidentiality of their
credentials (e.g., client implemented on a secure server with
restricted access to the client credentials), or capable of secure
client authentication using other means.
public
Clients incapable of maintaining the confidentiality of their
credentials (e.g., clients executing on the device used by the
resource owner, such as an installed native application or a web
browser-based application), and incapable of secure client
Since you are not using a pure web-browser application, or a mobile phone, but rather a web application with a secure backend, you should use a confidential client.
i.e. what is the client-secret used for? (Encryption)?
From the Keycloak documentation:
Confidential clients are required to provide a client secret when they
exchange the temporary codes for tokens. Public clients are not
required to provide this client secret.
Therefore, you need the client-secret because you have chosen a confidential client. The client-secret is used so that the application requesting the access token from Keycloak can be properly authenticated. In your case, the servers from the companies (using your app) requesting an access token from Keycloak. Consequently, Keycloak has to ensure that the server making the request is legit.
That is the purpose of the client-secret. It is similar to when you go to the ATM and request money, the bank knows that you are the owner of that resource (i.e, the bank account) if you have inserted the correct code (i.e., analogous to a client-secret).
Is it therefore a problem if the companies admins can theoretically
read the secret by decompiling the jar of the client-app I give them?
The client_secret has to be known by the application requesting the token (i.e., the company) and the authorization server (i.e., Keycloak). So in theory, if the companies do not mind their admins having access to such information, it should be fine for you. At the end of the day, the client-secret has to be known by both parties anyway. A way of mitigating potential problems with the leaking of client secrets is to change client-secrets once in a while, and communicate that change to interested parties.
As long as one company cannot reverse engineer the client secret of the other company you should be fine.
What can the redirect URI be for this case?
It should be the URL of the frontend leading page of the company deploying the client-app, after the user has been successfully authenticated.
Bear in mind, however:
You should take extra precautions when registering valid redirect URI
patterns. If you make them too general you are vulnerable to attacks.
See Threat Model Mitigation chapter for more information.
(source)