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
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.
|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
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
The application needs to be configured as a
OpenID Connect client with
Enabled and http://localhost:* as an allowed
Specialised in IAM (security, access control, identity management) and Open Source integration, settled in 2004 by IAM industry veteran, JANUA offers high value-added products and services to businesses and governements with a concern for Identity Management and Open Source components.
JANUA provides better security, build relationships, and enable new cloud, mobile, and IoT offerings from any device or connected thing.
Les derniers articles par Olivier Rivat (tout voir)
- Using Impersonation with Keycloak - 13 septembre 2019
- Offline Sessions and Offline tokens within Keycloak - 28 août 2019
- PKCE support with Keycloak 7.0 for mobile apps - 27 août 2019