keycloak-scim/docs/documentation/server_admin/topics/clients/oidc/con-confidential-client-credentials.adoc

[id="con-confidential-client-credentials_{context}"]

[[_client-credentials]]
= Confidential client credentials
[role="_abstract"]
If the <<_access-type, Client authentication>> of the client is set to *ON*, the credentials of the client must be configured under the *Credentials* tab.

.Credentials tab
image:images/client-credentials.png[Credentials Tab]

The *Client Authenticator* drop-down list specifies the type of credential to use for your client.

*Client ID and Secret*

This choice is the default setting. The secret is automatically generated. Click *Regenerate* to recreate the secret if necessary.

.Signed JWT
image:images/client-credentials-jwt.png[Signed JWT]

*Signed JWT* is "Signed Json Web Token".

When choosing this credential type you will have to also generate a private key and certificate for the client in the tab `Keys`. The private key will be used to sign the JWT, while the certificate is used by the server to verify the signature.

.Keys tab
image:images/client-oidc-keys.png[Keys tab]

Click on the `Generate new keys` button to start this process.

.Generate keys
image:images/generate-client-keys.png[]

. Select the archive format you want to use.
. Enter a *key password*.
. Enter a *store password*.
. Click *Generate*.

When you generate the keys, {project_name} will store the certificate and you download the private key and certificate for your client.

You can also generate keys using an external tool and then import the client's certificate by clicking *Import Certificate*.

.Import certificate
image:images/import-client-cert.png[Import Certificate]

. Select the archive format of the certificate.
. Enter the store password.
. Select the certificate file by clicking *Import File*.
. Click *Import*.

Importing a certificate is unnecessary if you click *Use JWKS URL*. In this case, you can provide the URL where the public key is published in https://datatracker.ietf.org/doc/html/rfc7517[JWK] format. With this option, if the key is ever changed, {project_name} reimports the key.

If you are using a client secured by {project_name} adapter, you can configure the JWKS URL in this format, assuming that https://myhost.com/myapp is the root URL of your client application:

[source,bash,subs=+attributes]
----
https://myhost.com/myapp/k_jwks
----

See link:{developerguide_link}[{developerguide_name}] for more details.

*Signed JWT with Client Secret*

If you select this option, you can use a JWT signed by client secret instead of the private key.

The client secret will be used to sign the JWT by the client.

*X509 Certificate*

{project_name} will validate if the client uses proper X509 certificate during the TLS Handshake.

.X509 certificate
image:images/x509-client-auth.png[]

The validator also checks the Subject DN field of the certificate with a configured regexp validation expression. For some
use cases, it is sufficient to accept all certificates. In that case, you can use `(.*?)(?:$)` expression.

Two ways exist for {project_name} to obtain the Client ID from the request:

* The `client_id` parameter in the query (described in Section 2.2 of the https://datatracker.ietf.org/doc/html/rfc6749[OAuth 2.0 Specification]).
* Supply `client_id` as a form parameter.