2026-09-27 · 6 min read · Rahul Chitturi
- oauth
- authorization
- security
OAuth Rich Authorization Requests carry structured authorization_details instead of forcing every permission into a flat scope string. Each array member has a type and type-specific fields understood by the authorization server and protected resource.
Requests fail when JSON is encoded twice, a type is not registered for the client, values conflict with scopes or resources, or downstream APIs interpret a broader authorization than the server granted.
Capture the logical JSON before transport
Record a sanitized authorization_details array, client registration, issuer metadata, scopes, resources, redirect URI, PAR or request-object usage, and the returned protocol error. Compare the logical value before form or URL encoding with what the server parses.
- Require a recognized type for every detail.
- Reject duplicate or ambiguous type-specific fields.
- Preserve JSON numbers and arrays without string coercion.
- Keep confidential account data out of browser URLs.
Follow details through the grant
Define how requested details are displayed for consent, narrowed by policy, represented in the authorization code, returned at the token endpoint, and enforced by the resource server. Do not assume the request itself proves that authorization was granted.
When a profile returns authorization_details in a token or introspection response, verify issuer, audience, token status, and the profile's binding rules before using the structured values. Keep unknown types fail-closed.
Test policy and serialization together
Use Flashman's JSON formatter for synthetic detail objects, URL tool for harmless encoded requests, JWT decoder for disposable token structures, and diff for requested-versus-granted values.
Test unsupported types, missing required fields, duplicate members, reordered keys, Unicode, large requests, PAR, signed request objects, narrowed consent, token refresh, multiple resources, API enforcement, and privacy-safe errors.