Support for PKCE (Proof Key for Code Exchange) in RH-SSO

Updated -

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-SSO 7.0.0 and 7.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 and 7.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 the 7.2.x and 7.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 the code_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-SSO 7.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 the Server 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 the Securing 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, the Authorization Code Flow with PKCE is only supported by public 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 for SPA - 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 a public client because it can not securely hide client credentials; hence the JavaScript adapter with PKCE support (as added in RH-SSO 7.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 with confidential 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 a Signed Json Web Token (JWT) or X509 Certificate validation (also called Mutual TLS) instead of a traditional Client ID and Secret method.
    Refer to the Server 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 the Authorization 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