PKCE support with Keycloak 7.0: Keycloak 7.0 has been released on Aug 25th 2019 with PKCE support. This represents a major breakthrough for all mobile apps to increase security and to mitigate malicious attacks
Public client security vulnerability
OAuth 2.0 [RFC6749] public clients are susceptible to the authorization code interception attack.
In this attack, the attacker intercepts the authorization code returned from the authorization endpoint within a communication path not protected by Transport Layer Security (TLS), such as interapplication communication within the client’s operating system.
Once the attacker has gained access to the authorization code, it can use it to obtain the access token.
What is PKCE and why Proof Key for Code Exchange by OAuth Public Clients
https://tools.ietf.org/html/rfc7636
To mitigate this attack, this extension utilizes a dynamically created cryptographically random key called « code verifier ». A unique code verifier is created for every authorization request, and its transformed value, called « code challenge », is sent to the authorization server to obtain the authorization code. The authorization code obtained is then sent to the token endpoint with the « code verifier », and the server compares it with the previously received request code so that it can perform the proof of possession of the « code verifier » by the client. This works as the mitigation since the attacker would not know this one-time key, since it is sent over TLS and cannot be intercepted.
Mitigation description
This specification adds additional parameters to the OAuth 2.0 Authorization and Access Token Requests, shown in abstract form A. The client creates and records a secret named the « code_verifier »and derives a transformed version « t(code_verifier) » (referred to the « code_challenge »), which is sent in the OAuth 2.0Authorization Request along with the transformation method « t_m ». B. The Authorization Endpoint responds as usual but records »t(code_verifier) » and the transformation method. C. The client then sends the authorization code in the Access TokenRequest as usual but includes the « code_verifier » secret generated at (A). D. The authorization server transforms « code_verifier » and compares t to « t(code_verifier) » from (B). Access is denied if they are not equal. An attacker who intercepts the authorization code at (B) is uable to redeem it for an access token, as they are not in possession of the »code_verifier » secret. |
Configuring keycloak with a PKCE public client
To configure PKCE with public client, the user should go to the client advanced settings menu and indicate either plain or S256 https://www.keycloak.org/docs/latest/server_admin/index.html#advanced-settings
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:
- (blank) : Keycloak does not apply PKCE unless the client sends PKCE’s parameters appropriately to keycloak’s authorization endpoint. It is the default setting.
- S256 : Keycloak applies to the client PKCE whose code challenge method is S256.
- plain : Keycloak applies to the client PKCE whose code challenge method is plain.
Client Configuration application
presentation
https://www.keycloak.org/docs/latest/securing_apps/index.html#_installed_adapter
The application needs to be configured as a public
OpenID Connect client with Standard Flow
Enabled
and https://localhost:* as an allowed Valid
Redirect URI
.
The KeycloakInstalled adapter
supports the PKCE [RFC 7636]
mechanism to provide additional protection during code to token
exchanges in the OIDC protocol. PKCE
can be enabled with the "enable-pkce":
true setting in the adapter configuration. Enabling PKCE is
highly recommended, to avoid code injection and code replay
attacks.
|
keycloak.json configuration
Usage
The KeycloakInstalled adapter
reads it’s configuration from META-INF/keycloak.json
on the classpath. Custom configurations can be supplied with an
InputStream or a KeycloakDeployment
through the KeycloakInstalled
constructor.
In the example below, the client configuration for desktop-app
uses the following keycloak.json :
{
"realm": "desktop-app-auth",
"auth-server-url": "https://localhost:8081/auth",
"ssl-required": "external",
"resource": "desktop-app",
"public-client": true,
"use-resource-role-mappings": true,
"enable-pkce": true
}
|
Pointers
- https://tools.ietf.org/html/rfc7636
- https://www.keycloak.org/docs/latest/server_admin/index.html#advanced-settings
- https://www.keycloak.org/docs/latest/securing_apps/index.html#_installed_adapter
- New Keycloak online training - 19 janvier 2022
- Sizing Keycloak or Redhat SSO projects - 8 juin 2021
- Keycloak.X Distribution - 28 janvier 2021