Skip to main content
HASP requires PKCE (RFC 7636) on every authorization code flow — for both public and confidential clients. PKCE prevents authorization code interception attacks by binding the code to a secret the client generates locally.

​
How it works

  1. Generate a code verifier — a cryptographically random string, 43–128 characters, using only [A-Z a-z 0-9 - . _ ~] (base64url without padding).
  2. Derive the code challenge — SHA-256 hash of the verifier, then base64url-encode the raw bytes (no padding).
  3. Send the challenge in the authorization URL as code_challenge with code_challenge_method=S256.
  4. Send the verifier at token exchange time as code_verifier.
HASP rejects any authorization request that omits code_challenge or sets code_challenge_method to anything other than S256.

​
Generating PKCE values

CODE_VERIFIER=$(openssl rand -base64 32 | tr '+/' '-_' | tr -d '=')
CODE_CHALLENGE=$(echo -n "$CODE_VERIFIER" | sha256sum | xxd -r -p | base64 | tr '+/' '-_' | tr -d '=')

​
Security notes

  • Store the verifier on your server or in session, never in a cookie or localStorage that is readable by third-party scripts.
  • Do not reuse a verifier — generate a fresh one for every authorization request.
  • The verifier is a secret until it is sent at token exchange. The challenge is safe to expose in the URL.

​
Why public clients still need PKCE

Public clients (browser apps, mobile apps, CLIs) cannot keep a client secret confidential. PKCE acts as a per-request credential: even if an attacker intercepts the authorization code, they cannot exchange it without the verifier. Confidential clients use PKCE in addition to their client secret for defense-in-depth.