PKCE
PKCE binds an authorization code to the client transaction that initiated it. Sigma's live discovery advertises S256 only. Do not use plain or silently fall back when hashing fails.
Request fields
| Stage | Field | Value |
|---|---|---|
| Authorization | code_challenge | Base64url SHA-256 digest of the verifier, without padding |
| Authorization | code_challenge_method | S256 |
| Token exchange | code_verifier | The original verifier |
Generate a new verifier with a cryptographically secure random generator for every attempt. A 32-byte random value encoded as base64url produces a 43-character verifier. Keep it in a short-lived server transaction tied to the initiating browser. The JavaScript guide contains the generator and authorization URL functions.
PKCE, state, and client authentication
PKCE does not replace state validation or the registered application's Bitcoin signature. Validate the browser-bound state transaction and issuer before exchanging a code. The current Sigma token hook requires X-Auth-Token signed by the registered accountPubkey's private key for authorization-code and refresh grants.
Do not accept the verifier from an arbitrary caller's POST body without matching it to your own transaction. Never place a verifier, WIF, or token in a URL, analytics event, error report, or browser log.
Failure handling
A missing/mismatched verifier, reused code, expired code, or inconsistent redirect URI can reject the exchange. Preserve the original callback URI and verifier until the transaction is consumed. After a failed or expired attempt, start a fresh authorization flow; do not retry a code indefinitely.
Test cases
Verify a correct S256 exchange succeeds and that a wrong verifier, missing verifier, changed redirect URI, mismatched state, and reused code are rejected. Run these integration tests with a staging client rather than production user accounts.