83 lines
3.6 KiB
Text
83 lines
3.6 KiB
Text
[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.
|
|
|
|
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://datatracker.ietf.org/doc/html/rfc6749[OAuth 2.0 Specification]).
|
|
* Supply `client_id` as a form parameter.
|