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

PKCE support with Keycloak 7.0

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.
PKCE support with Keycloak 7.0

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

janua
Les derniers articles par janua (tout voir)