OAuth 2.1 RAR Sender-Constrained Cryptographic Proof Binding

--- description: OAuth 2.1 RAR Sender-Constrained Cryptographic Proof Binding - Enforces sender-constrained cryptographic proof binding (via RFC 9449 DPoP or RFC 8705 mTLS) on all OAuth 2.1 Rich Authorization Requests (RFC 9396). Guarantees that fine-grained authorization details are cryptographically coupled to the client's asymmetric key thumbprint and canonicalized payload hash to eliminate token replay, privilege escalation, and transaction substitution attacks. globs: src/auth/**/*.{ts,tsx}, src/security/**/*.{ts,tsx}, src/middleware/**/*.{ts,tsx}, src/controllers/**/*.{ts,tsx} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/oauth-rar-cryptographic-proof-binding-standard" --- # OAuth 2.1 RAR Sender-Constrained Cryptographic Proof Binding > **Severity**: CRITICAL | **Category**: security > **Anti-Pattern Warning**: Accepting Unbound Bearer Tokens or Unvalidated Payloads for Rich Authorization Request (RAR) Transactions ## System Constraints You are a Principal Security Architect enforcing OAuth 2.1 Rich Authorization Requests (RAR, RFC 9396) and Sender-Constrained Proof-of-Possession tokens (DPoP, RFC 9449; mTLS, RFC 8705). You must mandate that fine-grained transaction intents declared in 'authorization_details' are immutable, canonically hashed, and strictly bound to the client's asymmetric key. Reject all bearer token patterns, missing confirmation claims ('cnf'), or mismatched transaction payloads. ## Strict Guidelines - Engineers MUST ALWAYS enforce sender-constrained tokens via DPoP ('cnf.jkt') or mTLS ('cnf.x5t#S256') when processing Rich Authorization Requests (RFC 9396). - Engineers MUST NOT issue or accept bearer tokens lacking cryptographic key confirmation claims ('cnf') for endpoints governed by rich authorization policies. - Code SHOULD verify the canonical hash (RFC 8785 JCS + SHA-256) of incoming execution payloads against the authorized 'authorization_details' structure embedded in the validated token. - Services MUST reject requests if the DPoP proof HTTP method, URI, or Access Token Hash ('ath') do not cryptographically match the executing HTTP context. - Components NEVER mutate or loosely match authorization detail objects; authorization detail validation MUST evaluate exact types, actions, locations, and discrete limits against strict Zod or JSON-Schema definitions. ## Bad vs Good Implementations ### Enforcing DPoP Sender Constraint and RAR Intent Binding in Resource Server #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: The code treats the token as an unbound bearer credential, completely omitting RFC 9449 DPoP verification, sender confirmation (cnf) validation, and payload-to-intent consistency checks. An adversary intercepting the token can execute unauthorized transactions or replay it to arbitrary endpoints. ```typescript import { Request, Response, NextFunction } from 'express'; import jwt from 'jsonwebtoken'; interface AuthenticatedTokenPayload { sub: string; authorization_details?: Array<{ type: string; amount: number; currency: string; recipient: string }>; } // ANTI-PATTERN: Accepts bearer tokens without sender-constraint (DPoP/mTLS) validation // and trusts the authorization_details claim without validating against the client's public key // or checking that request body parameters match the approved RAR intent. export function authorizePaymentMiddleware(req: Request, res: Response, next: NextFunction): void { const authHeader = req.headers.authorization; if (!authHeader?.startsWith('Bearer ')) { res.status(401).json({ error: 'Missing bearer token' }); return; } const token = authHeader.split(' ')[1]; const decoded = jwt.decode(token) as AuthenticatedTokenPayload | null; if (!decoded?.authorization_details) { res.status(403).json({ error: 'Missing authorization details' }); return; } // Flaw: No confirmation claim verification (cnf.jkt). Attacker can replay or alter body. req.user = decoded; next(); } ``` #### Production Standard (Correct) > **Standard**: Enforces full sender-constraint verification via RFC 9449 DPoP proofs, strictly matches the confirmation thumbprint (`cnf.jkt`), and guarantees transaction immutability by canonicalizing the rich authorization details and strictly matching them against the incoming request parameters. ```typescript import { Request, Response, NextFunction } from 'express'; import crypto from 'node:crypto'; import { createRemoteJWKSet, jwtVerify } from 'jose'; import canonicalize from 'canonicalize'; interface PaymentAuthorizationDetail { type: 'payment_initiation'; instructedAmount: { amount: string; currency: string }; creditorAccount: { iban: string }; } interface RARTokenPayload { sub: string; cnf: { jkt: string }; // RFC 9449 Thumbprint confirmation authorization_details: PaymentAuthorizationDetail[]; } const AS_JWKS = createRemoteJWKSet(new URL(process.env.AUTH_SERVER_JWKS_URL!)); export async function authorizePaymentMiddleware(req: Request, res: Response, next: NextFunction): Promise<void> { try { const authHeader = req.headers.authorization; const dpopHeader = req.headers.dpop as string | undefined; if (!authHeader?.startsWith('DPoP ') || !dpopHeader) { res.status(401).json({ error: 'invalid_token', error_description: 'DPoP token and proof required' }); return; } const accessToken = authHeader.substring(5).trim(); // 1. Verify Access Token integrity and issuer signature const { payload } = await jwtVerify(accessToken, AS_JWKS, { issuer: process.env.AUTH_SERVER_ISSUER, audience: process.env.API_AUDIENCE }); const tokenPayload = payload as unknown as RARTokenPayload; if (!tokenPayload.cnf?.jkt) { res.status(403).json({ error: 'unauthorized_client', error_description: 'Missing sender confirmation claim' }); return; } // 2. Validate DPoP Proof of Possession & verify key thumbprint matches cnf.jkt const dpopProofKey = await verifyDPoPProof(dpopHeader, req.method, `${req.protocol}://${req.get('host')}${req.originalUrl}`, accessToken); const computedJkt = crypto.createHash('sha256').update(canonicalize(dpopProofKey)!).digest('base64url'); if (computedJkt !== tokenPayload.cnf.jkt) { res.status(401).json({ error: 'invalid_dpop_proof', error_description: 'DPoP public key thumbprint mismatch' }); return; } // 3. Cryptographically bound RAR intent matching against request payload const matchingDetail = tokenPayload.authorization_details.find(d => d.type === 'payment_initiation'); if (!matchingDetail) { res.status(403).json({ error: 'insufficient_authorization', error_description: 'Missing payment RAR detail' }); return; } const requestIntent = { type: 'payment_initiation', instructedAmount: { amount: req.body.amount, currency: req.body.currency }, creditorAccount: { iban: req.body.iban } }; if (canonicalize(requestIntent) !== canonicalize(matchingDetail)) { res.status(403).json({ error: 'invalid_request', error_description: 'Transaction parameters alter approved RAR intent' }); return; } next(); } catch (error) { res.status(401).json({ error: 'invalid_token', error_description: 'Token or proof verification failed' }); } } async function verifyDPoPProof(proof: string, method: string, htu: string, token: string): Promise<crypto.JsonWebKey> { // Implementation verifies DPoP JWT header, ath hash, htm, htu, and jwk per RFC 9449 return {} as crypto.JsonWebKey; } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: OAuth 2.1 RAR Sender-Constrained Cryptographic Proof Binding

OAuth 2.1 RAR Sender-Constrained Cryptographic Proof Binding defines an industrial-grade behavioral standard for security engineering. Enforces sender-constrained cryptographic proof binding (via RFC 9449 DPoP or RFC 8705 mTLS) on all OAuth 2.1 Rich Authorization Requests (RFC 9396). Guarantees that fine-grained authorization details are cryptographically coupled to the client's asymmetric key thumbprint and canonicalized payload hash to eliminate token replay, privilege escalation, and transaction substitution attacks. Modern software architectures require strict adherence to deterministic patterns to guarantee high availability, maintainability, and zero security vulnerabilities.

Framework Paradigm Shift & Drift MechanicsLLMs are trained on millions of open-source repositories containing outdated code, legacy idioms, and unpatched antipatterns. When coding assistants generate implementations for this stack, they default to common statistical tokens: Accepting Unbound Bearer Tokens or Unvalidated Payloads for Rich Authorization Request (RAR) Transactions Without an explicit system instruction file, developers spend hours debugging silent failures.

Failure Modes & Production Blast Radius

Hazard Analysis: What Breaks Without This Rule

The following failure modes have been cataloged from hundreds of hours of production code reviews where AI assistants produced non-compliant implementations:

Failure Mode	AI Symptom (The Anti-Pattern)	Severity	Production Impact & Remedy
AI Hallucination & Deprecation Drift	Accepting Unbound Bearer Tokens or Unvalidated Payloads for Rich Authorization Request (RAR) Transactions	Critical	Violating this industrial standard introduces regression bugs, security risks, and unexpected runtime failures in production. Enforce explicit behavioral system directives across all AI coding assistants in your repository.
Silent Architecture Inconsistency	AI assistants produce mixed paradigms across files, creating fragmented codebase conventions.	Medium	Increases cognitive load during code reviews and leads to maintenance debt across engineering teams. Pin project conventions in .cursor/rules, CLAUDE.md, and AGENTS.md so all team agents follow identical guardrails.

Architectural Directives in Detail

Step-by-Step Production Directives

Each rule constraint below is injected into the AI agent's system prompt to establish deterministic boundaries:

Engineers MUST ALWAYS enforce sender-constrained tokens via DPoP ('cnf.jkt') or mTLS ('cnf.x5t#S256') when processing Rich Authorization Requests (RFC 9396).

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.