2026-09-27 · 8 min read
- oauth
- authorization
- security
Rich Authorization Requests add the authorization_details parameter to OAuth so clients can request structured permissions. Its JSON array contains typed objects whose members can describe actions, locations, accounts, amounts, or other profile-defined authorization data.
RAR improves expressiveness but does not make client input authoritative. The authorization server still authenticates the transaction, applies client and user policy, obtains meaningful consent, and records exactly what was granted.
Register a strict detail-type vocabulary
For every supported type, define required and optional members, JSON types, allowed values, URI comparison, duplicate behavior, size limits, and the client registrations permitted to request it. Unknown types or critical fields should fail closed.
- Keep type identifiers stable and documented.
- Do not coerce strings, numbers, and arrays.
- Reject ambiguous duplicate detail objects.
- Minimize sensitive transaction data.
Protect the browser-facing request
Serialize the logical JSON once according to the selected authorization-request transport. Large or confidential detail sets belong in a pushed authorization request or an appropriately protected request object rather than a long browser URL.
Bind authorization details to the same transaction record as state, PKCE, nonce, issuer, redirect URI, resources, and scopes. Apply the profile's rules for interactions among those parameters instead of independently unioning their permissions.
Present and record the grant precisely
Translate requested details into consent language that identifies the action and affected resources without exposing internal field names. Allow narrowing only where the profile defines a deterministic representation of the granted result.
Store requested and granted forms separately with privacy-aware audit metadata. The authorization code must remain bound to the granted authorization, client, redirect transaction, code challenge, and intended resource.
Carry authorization to the resource server
Issue a token representation that protected resources can validate according to the ecosystem profile, whether through signed claims, introspection, or server-side state. Validate issuer, audience, token status, type, and binding before enforcing authorization details.
Map each detail type to explicit API actions and object identifiers. Reject unknown or malformed details and avoid falling back to a broader scope interpretation when structured authorization cannot be processed.
Build protocol and policy fixtures
Use Flashman's JSON formatter for synthetic details, URL tool for harmless request transport, JWT decoder for disposable structures, diff for requested and granted forms, and hash tool for public fixture identity.
Test unsupported types, missing fields, duplicates, Unicode, large values, PAR, signed request objects, conflicting scopes and resources, consent narrowing, denial, code replay, refresh behavior, multiple APIs, token introspection, policy upgrades, and redacted telemetry.