Confidential access type is for server-side clients that need to perform a browser login and require a client secret when they turn an access code into an access token,
(see https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.3[Access Token Request] in the OAuth 2.0 spec for more details). This type should be used for server-side applications.
Public access type is for client-side clients that need to perform a browser login. With a client-side application there is no way to keep a secret safe. Instead it is very important to restrict access by configuring correct redirect URIs for the client.
If enabled, the session id is included in the logout token when a backchannel logout request is sent.
This results in only logging out a specific session. If disabled, all sessions of the corresponding
user will be logged out.
*Backchannel Logout Revoke Offline Sessions*
If enabled, a `revoke_offline_access` event is added to the logout token. This should result in also logging out offline
sessions with a backchannel logout request. This event is not specified by the https://openid.net/specs/openid-connect-backchannel-1_0.html[OpenID Connect specification]
and may have to change in the future. Keycloak itself will respect the `revoke_offline_access` in a logout token when receiving
Mutual TLS binds an access token and a refresh token with a client certificate exchanged during TLS handshake. This prevents an attacker who finds a way to steal these tokens from exercising the tokens. This type of token is called a holder-of-key token. Unlike bearer tokens, the recipient of a holder-of-key token can verify whether the sender of the token is legitimate.
If the following conditions are satisfied on a token request, {project_name} will bind an access token and a refresh token with a client certificate and issue them as holder-of-key tokens. If all conditions are not met, {project_name} rejects the token request.
* A token request is sent to the token endpoint in an authorization code flow or a hybrid flow
* On TLS handshake, {project_name} requests a client certificate and a client send its client certificate
* On TLS handshake, {project_name} successfully verifies the client certificate
To enable mutual TLS in {project_name}, see <<_enable-mtls-wildfly, Enable mutual SSL in WildFly>>.
In the following cases, {project_name} will verify the client sending the access token or the refresh token; if verification fails, {project_name} rejects the token.
* A token refresh request is sent to the token endpoint with a holder-of-key refresh token
* A UserInfo request is sent to UserInfo endpoint with a holder-of-key access token
* A logout request is sent to Logout endpoint with a holder-of-key refresh token
Please see https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-08#section-3[Mutual TLS Client Certificate Bound Access Tokens] in the OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens for more details.
When an attacker steals an authorization code that was issued to a legitimate client, PKCE prevents the attacker from receiving the tokens that apply to that code.
The administrator can select the following three options:
*Proof Key for Code Exchange Code Challenge Method*
* (blank) : {project_name} does not apply PKCE unless the client sends PKCE's parameters appropriately to {project_name}'s authorization endpoint. It is the default setting.
{project_name} can encrypt ID token according to the https://datatracker.ietf.org/doc/html/rfc7516[Json Web Encryption (JWE)] specification. The administrator can determine whether encrypting ID token or not per client. This feature is disabled as default.
The key for encrypting ID token is called Content Encryption Key (CEK). {project_name} and a client need to negotiate which CEK is used and how to deliver it. The way to do so is called Key Management Mode.
JWE specification determines 5 types of Key Management Mode. {project_name} supports Key Encryption among them.
In Key Encryption, the client generates a key pair of asymmetric cryptography. The public key is used to encrypt CEK. {project_name} generates CEK per ID token, encrypts the ID token by this generated CEK and encrypts this CEK by this client's public key. The client decrypts this encrypted CEK by their private key, and decrypt the ID token by decrypted CEK. Therefore, any party other than the client is not able to decrypt ID token.
The client needs to pass their public key for encrypting CEK onto {project_name}. {project_name} supports downloading public keys from the URL the client provides. The client needs to provide their public keys according to https://datatracker.ietf.org/doc/html/rfc7517[Json Web Keys (JWK)] specification. The detailed procedure is as follows:
Key Encryption's algorithms are defined in the https://datatracker.ietf.org/doc/html/rfc7518#section-4.1[Json Web Algorithm (JWA)] specification. {project_name} supports RSAES-PKCS1-v1_5(RSA1_5), RSAES OAEP using default parameters (RSA-OAEP), and RSAES OAEP 256 using SHA-256 and MFG1 (RSA-OAEP-256). The detailed procedure to select this algorithm is as follows:
ID token encryption algorithms by CEK are also defined in the https://datatracker.ietf.org/doc/html/rfc7518#section-5.1[JWA] specification. {project_name} supports AES_CBC_HMAC_SHA2 algorithms and AES GCM algorithms. The detailed procedure to select this algorithm is as follows:
