Get the FREE Ultimate OpenClaw Setup Guide →
I

OAuth

Verified

@ivangdavila

npx machina-cli add skill @ivangdavila/oauth --openclaw
Files (1)
SKILL.md
3.6 KB

Flow Selection

  • Authorization Code + PKCE: use for all clients—web apps, mobile, SPAs
  • Client Credentials: service-to-service only—no user context
  • Implicit flow: deprecated—don't use; was for SPAs before PKCE existed
  • Device Code: for devices without browsers (TVs, CLIs)—user authorizes on separate device

PKCE (Proof Key for Code Exchange)

  • Required for public clients (SPAs, mobile), recommended for all
  • Generate code_verifier: 43-128 char random string, stored client-side
  • Send code_challenge: SHA256 hash of verifier, sent with auth request
  • Token exchange includes code_verifier—server verifies against stored challenge
  • Prevents authorization code interception—attacker can't use stolen code without verifier

State Parameter

  • Always include state in authorization request—prevents CSRF attacks
  • Generate random, unguessable value; store in session before redirect
  • Verify returned state matches stored value before processing callback
  • Can also encode return URL or other context (encrypted or signed)

Redirect URI Security

  • Register exact redirect URIs—no wildcards, no open redirects
  • Validate redirect_uri on both authorize and token endpoints
  • Use HTTPS always—except localhost for development
  • Path matching is exact—/callback/callback/

Tokens

  • Access token: short-lived (minutes to hour), used for API access
  • Refresh token: longer-lived, used only at token endpoint for new access tokens
  • ID token (OIDC): JWT with user identity claims—don't use for API authorization
  • Don't send refresh tokens to resource servers—only to authorization server

Scopes

  • Request minimum scopes needed—users trust granular requests more
  • Scope format varies: openid profile email (OIDC), repo:read (GitHub-style)
  • Server may grant fewer scopes than requested—check token response
  • openid scope required for OIDC—triggers ID token issuance

OpenID Connect

  • OIDC = OAuth 2.0 + identity layer—adds ID token and UserInfo endpoint
  • ID token is JWT with sub, iss, aud, exp + profile claims
  • Verify ID token signature before trusting claims
  • nonce parameter prevents replay attacks—include in auth request, verify in ID token

Security Checklist

  • HTTPS everywhere—tokens in URLs must be protected in transit
  • Validate iss and aud in tokens—prevents token confusion across services
  • Bind authorization code to client—code usable only by requesting client
  • Short authorization code lifetime (10 min max)—single use
  • Implement token revocation for logout/security events

Common Mistakes

  • Using access token as identity proof—use ID token for authentication
  • Storing tokens in localStorage—vulnerable to XSS; prefer httpOnly cookies or memory
  • Not validating redirect_uri—allows open redirect attacks
  • Accepting tokens from URL fragment in backend—fragment never reaches server
  • Long-lived access tokens—use short access + refresh pattern

Token Endpoints

  • /authorize: user-facing, returns code via redirect
  • /token: backend-to-backend, exchanges code for tokens; requires client auth for confidential clients
  • /userinfo (OIDC): returns user profile claims; requires access token
  • /revoke: invalidates tokens; accepts access or refresh token

Client Types

  • Confidential: can store secrets (backend apps)—uses client_secret
  • Public: cannot store secrets (SPAs, mobile)—uses PKCE only
  • Never embed client_secret in mobile apps or SPAs—it will be extracted

Source

git clone https://clawhub.ai/ivangdavila/oauthView on GitHub

Overview

Learn how to implement OAuth 2.0 and OpenID Connect securely, selecting the right flows (Authorization Code + PKCE, Client Credentials, Device Code), handling tokens, and enforcing best practices to protect users and services.

How This Skill Works

The skill explains flow selection (e.g., Authorization Code + PKCE for web/mobile/SPAs, Client Credentials for service-to-service, Device Code for devices). It covers PKCE with code_verifier and code_challenge, state parameter, redirect URI validation, token types (access, refresh, ID token), and OIDC verification steps, including nonce and signature checks.

When to Use It

  • Building web apps, mobile apps, or SPAs that require user login (Authorization Code + PKCE).
  • Service-to-service integrations where there is no user context (Client Credentials).
  • Devices without browsers (Device Code) where user authenticates on another device.
  • Migrating from the deprecated Implicit flow to PKCE-enabled Authorization Code flow.
  • Implementing OpenID Connect to obtain ID tokens and user identity claims.

Quick Start

  1. Step 1: Choose the flow (Authorization Code + PKCE for user login, Client Credentials for service-to-service, or Device Code for devices).
  2. Step 2: Implement PKCE for public clients: generate code_verifier, derive code_challenge, and attach to the authorization request; store verifier client-side.
  3. Step 3: Exchange the authorization code at /token with the code_verifier, verify the ID token and access token, enforce nonce, and validate redirect_uri and issuer/audience. Ensure HTTPS and proper token handling.

Best Practices

  • Use Authorization Code + PKCE for public clients and require code_verifier during token exchange.
  • Always include and validate the state parameter to prevent CSRF attacks.
  • Register exact redirect URIs, validate redirect_uri on both authorize and token endpoints, and require HTTPS.
  • Use short-lived access tokens and reserve refresh tokens for the authorization server; do not expose refresh tokens to resource servers.
  • For OpenID Connect, verify ID token signatures, use nonce to prevent replay, and treat the ID token as authentication evidence rather than API authorization.

Example Use Cases

  • A web app implementing OAuth 2.0 with PKCE to log in users and fetch profile data via OIDC.
  • A mobile app using Authorization Code + PKCE to securely obtain tokens without exposing secrets.
  • A SPA that uses PKCE and the /authorize + /token endpoints to authenticate users.
  • A backend service using Client Credentials to access a protected API without user context.
  • A smart TV app using Device Code flow to authorize a user on a separate device.

Frequently Asked Questions

Add this skill to your agents
Sponsor this space

Reach thousands of developers