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

[[_client-credentials]]

==== Confidential Client Credentials

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 `Regenerate Secret` button recreates the secret if necessary.

*Signed JWT*

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

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

To use the `Signed JWT` credential type, a private key and certificate must be generated for the client. The private key is used to sign the JWT and the certificate is used by the server to verify the signature. Click the `Generate new keys and certificate` button to begin 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 must 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 the `Import Certificate` button.

.Import Certificate
image:{project_images}/import-client-cert.png[]

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

It is not necessary to import a certificate if you click the `Use JWKS URL` switch. 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, you must 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.

NOTE: This option requires mutual TLS in {project_name}. See <<_enable-mtls-wildfly, Enable mutual SSL in WildFly>>.

.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://tools.ietf.org/html/rfc6749[OAuth 2.0 Specification]).
* Supply `client_id` as a form parameter.