keycloak-scim/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, access type>> of the client is set to *confidential*, the credentials of the client must be configured under the *Credentials* tab.

.Credentials tab
image:{project_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 for you and the clicking *Regenerate Secret*  recreates the secret if necessary.

.Signed JWT
image:{project_images}/client-credentials-jwt.png[]

*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[]

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

.Generate keys
image:{project_images}/generate-client-keys.png[]

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

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:{project_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://self-issued.info/docs/draft-ietf-jose-json-web-key.html[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.

WARNING: {project_name} caches public keys of OIDC clients. If the private key of your client is compromised, update your keys and clear the key cache. See <<_clear-cache, Clearing the cache>> section 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.

ifeval::["{kc_dist}" == "wildfly"]
NOTE: This option requires mutual TLS in {project_name}. See <<_enable-mtls-wildfly, Enable mutual SSL in WildFly>>.
endif::[]

.X509 certificate
image:{project_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.