Support for PKCE (Proof Key for Code Exchange) in RH-SSO
Abstract
OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. The RFC#7636: Proof Key for Code Exchange by OAuth Public Clients specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange
(PKCE
, pronounced "pixy"). 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.
This article details on how RH-SSO (based on upstream project Keycloak) actually supports PKCE.
Environment
- Red Hat Single Sign-On (RH-SSO)
- 7
Support Levels for PKCE in RH-SSO releases
-
There was no support for
PKCE
in the RH-SSO7.0.0
and7.1.0
GA releases. -
Starting from the RH-SSO
7.2.0
GA release, support for Proof Key for Code Exchange by OAuth Public Clients has been added as per KEYCLOAK-2604 Feature Request implementation in Keycloak upstream 3.1.0.However, it is to note that in
7.2.0
and7.3.0
releases, the support is basically limited at the RH-SSO Server Side component. So, the PKCE support is not present in any of the7.2.x
and7.3.x
RH-SSO clients adapters.
What this basically means for the server-side support is that if you use 3rd party OIDC adapter that enables PKCE, then you can manually add thecode_verifier
,code_challenge
,code_challenge_method
parameters as described in the PKCE specification, and the RH-SSO server will handle it. -
In RH-SSO
7.4.0
GA release version, built-in support for the PKCE has been added to RH-SSO adapters, but this PKCE support is only limited to the JavaScript adapter for now.This was done in Keycloak upstream version 7.0.0 as per Feature Request and Enhancement issues tracker KEYCLOAK-1033 and KEYCLOAK-10303.
RH-SSO7.4.0
release is based on the keycloak upstream version 9.0.3 (see Red Hat Single Sign-On (RH-SSO) Releases Roadmap).For documentation, see the
Proof Key for Code Exchange
section as under theServer Administration Guide
chapter for Managing Clients: 8.1. OIDC Clients -> 8.1.1. Advanced Settings -> Proof Key for Code Exchange (PKCE).
See also, the JavaScript Adapter documentation under theSecuring Applications and Services Guide
chapter for OpenID Connect Adapters: 2.2. JavaScript Adapter -> 2.2.5. JavaScript Adapter Reference -> 2.2.5.3. Methods -> pkceMethod, where it mentions this option:pkceMethod - The method for Proof Key Code Exchange (PKCE) to use. Configuring this value enables the PKCE mechanism. Available options: "S256" - The SHA256 based PKCE method
Important Notes
-
PKCE is intended to be used in
public
clients in order to give an extra security. Hence, theAuthorization Code Flow
withPKCE
is only supported bypublic
clients.It is typically used for clients facing applications which should be
public
clients with usually the JavaScript adapter. The more common use case is forSPA - Single Page Application
which is mostly an HTML5/JavaScript based application consisting of JavaScript code wrapped in an HTML code shell. A Single Page Application uses apublic
client because it can not securely hide client credentials; hence the JavaScript adapter with PKCE support (as added in RH-SSO7.4.0
release) will really help.This blog (which is not maintained by Red Hat, btw) discusses about Single-Page Application (SPA) and how to secure the same with Keycloak using OAuth 2.0 Authorization Code Flow and PKCE.
-
Support for
PKCE
withconfidential
clients has been rejected in Keycloak upstream as per KEYCLOAK-11438.PKCE is not really relevant for
confidential
type of clients, as those are able to sufficiently authenticate themselves and as such are not vulnerable to the issue that PKCE protects against.For server-side applications (which are typically the ones that should be using
confidential
clients), PKCE is not much relevant. For additional security for such server-side applications, it is suggested to consider authenticating with aSigned Json Web Token (JWT)
orX509 Certificate
validation (also calledMutual TLS
) instead of a traditionalClient ID and Secret
method.
Refer to theServer Administration Guide
chapter for Managing Clients, as under 8.1. OIDC Clients -> 8.1.2. Confidential Client Credentials. -
When using the OIDC
Authorization Code Flow
, it would be very hard for an attacker to actually compromise RH-SSO generated authorization codes.Red Hat Single Sign-On generates a cryptographically strong random value for its authorization codes and which makes it quite hard to guess an access token.
Also, an authorization code can only be used once to obtain an access token. In the RH-SSO Admin Console, you can specify how long an authorization code is valid for on the timeouts configuration page. For instance, the
Client login timeout
is the "maximum time that a client has to finish theAuthorization Code Flow
transaction. This value should be really short, as short as a few seconds and just long enough for the client to make the request to obtain a token from the code.
Comments