[[_client-credentials]]

==== Confidential Client Credentials

If you've set the client's <<_access-type, access type>> to `confidential` in the client's
`Settings` tab, a new `Credentials` tab will show up. As part of dealing with this
type of client you have to configure the client's credentials.

.Credentials Tab
image:{project_images}/client-credentials.png[]

The `Client Authenticator` list box specifies the type of credential you are going to use for your confidential client.
It defaults to client ID and secret.  The secret is automatically generated for you and the `Regenerate Secret`
button allows you to recreate this secret if you want or need to.

Alternatively, you can opt to use a signed Json Web Token (JWT) or x509 certificate validation (also called Mutual TLS) instead of a secret.

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

When choosing this credential type you will have to also generate a private key and certificate for the client.  The private key
will be used to sign the JWT, while the certificate is used by the server to verify the signature.  Click on the
`Generate new keys and certificate` button to start this process.

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

When you generate these keys, {project_name} will store the certificate, and you'll need to download the private key
and certificate for your client to use.  Pick the archive format you want and specify the password for the private key
and store.

You can also opt to
generate these via an external tool and just import the client's certificate.

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

There are multiple formats you can import from, just choose the archive format you have the certificate stored in,
select the file, and click the `Import` button.

Finally note that you don't even need to import certificate if you choose to `Use JWKS URL` . In that case, you can provide the URL where
client publishes it's public key in https://self-issued.info/docs/draft-ietf-jose-json-web-key.html[JWK] format. This is flexible because when
client changes it's keys, {project_name} will automatically download them without need to re-import anything on {project_name} side.

If you use client secured by {project_name} adapter, you can configure the JWKS URL like https://myhost.com/myapp/k_jwks assuming that https://myhost.com/myapp is the
root URL of your client application. See link:{developerguide_link}[{developerguide_name}] for additional details.

WARNING: For the performance purposes, {project_name} caches the public keys of the OIDC clients. If you think that private key of your client
was compromised, it is obviously good to update your keys, but it's also good to clear the keys cache. See <<_clear-cache, Clearing the cache>>
section for more details.

.Signed JWT with Client Secret

If you select this option in the `Client Authenticator` list box, you can use a JWT signed by client secret instead of the private key.

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

.X509 Certificate

By enabling this option {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>>.

.Import Certificate
image:{project_images}/x509-client-auth.png[]

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

There are two ways for {project_name} to obtain the Client ID from the request. The first option is the `client_id`
parameter in the query (described in Section 2.2 of the https://tools.ietf.org/html/rfc6749[OAuth 2.0 Specification]).
The second option is to supply `client_id` as a query parameter.