OAuth 2.0 Rich Authorization Requests

OAuth scope strings can become awkward when an API needs structured authorization information, such as a particular account, payment recipient, amount, or combination of permitted actions. Encoding every variation in a separate scope creates a vocabulary and interoperability problem.

Rich Authorization Requests supplies a structured way to express those requirements while retaining OAuth's grant and token flow. It specifies representation and processing rules; it does not infer permission requests from natural-language instructions or verify an agent's plan.

The authorization_details parameter, whose value is an array of typed JSON objects describing requested access.

Rules for carrying, validating, comparing, and returning authorization details during authorization and token processing.

Resource-server delivery mechanisms and metadata for advertising supported types, together with security and privacy requirements.

An API defines authorization-detail types and their allowed fields. Every object requires a type identifier. Optional common fields include locations, actions, datatypes, identifier, and privileges; type-specific fields can express information such as payment data. Repeated objects of the same type are permitted, and a type identifier need not resolve to a downloadable schema.

The client sends authorization_details in an authorization request, optionally alongside scope for independent requirements. The authorization server validates each object against the type definition and rejects unknown types, unknown fields, incorrect field types, invalid values, or missing required fields. Consent presents the combined requirements, and the resulting grant records the approved authorization.

When requesting a token, the client can request authorization details allowed by the existing grant or client policy. The authorization server applies type-specific comparison semantics and returns the details assigned to the token. It also makes the approved details available to the resource server, for example through a JWT access token or token introspection, so that the resource server can enforce them.

Deployments advertise supported types in server metadata and define how consent, enrichment, and enforcement work for each type. Request integrity and confidential transport protect sensitive details. The privacy guidance limits disclosure to the client and resource servers according to their need to know.

This is a standards specification, not an experimental research paper. It includes protocol examples and normative implementation requirements, with no benchmark, model comparison, or empirical effectiveness results.

Implementation assessment follows those requirements: object validation, consent consistency, grant-to-token comparison, resource-server enforcement, supported-type metadata, and protection against tampering or unintended disclosure. These are conformance concerns described by the specification, not experiments conducted by its authors.