Skip to main content
PKCE (Proof Key for Code Exchange) secures the OAuth2 flow for applications that cannot store a client_secret — such as single-page apps (React, Vue, Angular), native mobile apps, and client-side JavaScript. Instead of a client secret, you use a one-time code_verifier and its code_challenge to prove you initiated the authorization request.

Prerequisites

Before you implement this flow, ensure you have:
  • OAuth2 clientRegister your app in Client Center / Manage Account to get client_id (no client_secret required for PKCE)
  • Redirect URI — Must be pre-registered in Client Center / Manage Account; use the exact URL where your app handles the callback (e.g., https://yourapp.com/oauth/callback)
  • Runtime support — Browser with crypto.subtle or Node.js 18+ / Python 3.8+ for generating code_verifier and code_challenge
  • Storage for code_verifier — Store the code_verifier between the redirect and callback (e.g., sessionStorage in browser, secure storage in mobile apps)
PKCE is recommended for all public clients (SPAs, mobile apps). Even if your backend eventually handles the token exchange, starting with PKCE improves security.

How PKCE works

  1. Generate a random code_verifier (43–128 characters).
  2. Create a code_challenge = Base64URL(SHA256(code_verifier)).
  3. Include code_challenge and code_challenge_method=S256 in the authorization URL.
  4. Store code_verifier until the callback.
  5. When exchanging the code for tokens, send code_verifier instead of client_secret. Aries verifies it matches the challenge.

Step 1: Generate code_verifier, code_challenge, and redirect

Generate a cryptographically random code_verifier, derive the code_challenge, and redirect the user to Aries. Store the code_verifier so you can send it when exchanging the code. Endpoint: https://app.aries.com/oauth2/authorize Query parameters (including PKCE):
Browser (SPA) example — use sessionStorage to persist code_verifier across the redirect:
JavaScript

Step 2: Handle the callback

After the user approves, Aries redirects to your redirect_uri with the authorization code and state. Retrieve the stored code_verifier and exchange the code for tokens. Do not use the code twice — exchange it once and immediately.
Browser (SPA) callback — exchange happens from the client:
JavaScript

Step 3: Exchange the code for tokens (with code_verifier)

Send the authorization code and code_verifier to the token endpoint. Do not include client_secret — PKCE uses code_verifier instead. Endpoint: POST https://api.aries.com/v1/oauth2/token Request body (PKCE):
Response (same as Authorization Code flow):

Step 4: Make authenticated API requests

Use the access token in the Authorization header for every API request.

Step 5: Refresh the access token

Access tokens expire after expires_in seconds (typically 1 hour). Use the refresh token to get a new access token. For public clients (SPAs, mobile apps without a backend), refresh typically requires client_secret. If your PKCE app has no backend, consider using a Backend-for-Frontend (BFF) to perform refresh, or prompt the user to re-authenticate when the access token expires. Endpoint: POST https://api.aries.com/v1/oauth2/token If you have a backend (e.g., BFF or server-side PKCE), use the same refresh format as the Authorization Code flow:

Complete SPA example (React)

Minimal React example for a client-side PKCE flow:
JavaScript

Next steps

OAuth2 Overview

Scopes, security, rate limits, and troubleshooting.

Authorization Code Flow

Server-side flow with client_secret.

Token API Reference

Interactive token endpoint reference.

Quick Start

Get started in minutes.