RAR type specification

Vault supports the vault:path_access RAR type for fine-grained authorization. Each authorization detail object in the authorization_details claim must conform to the following structure:

Field	Type	Required	Description
`type`	string	Yes	Must be `vault:path_access` to indicate a Vault path access constraint.
`path`	string	Yes	The Vault path the constraint applies to. Supports exact path matching.
`capabilities`	array of strings	Yes	List of capabilities permitted for the path. Valid values: `read`, `create`, `update`, `delete`, `list`, `sudo`, `patch`, `subscribe`, `recover`, `deny`.
`allowed_parameters`	object	No	Map of parameter names to arrays of values that restricts which request parameters and values Vault permits. An empty array `[]` allows any value for that parameter.
`denied_parameters`	object	No	Map of parameter names to arrays of denied values. Blocks specific parameter values. Takes precedence over `allowed_parameters`.
`required_parameters`	array of strings	No	List of parameter names that must be present in the request. Vault rejects requests missing any required parameter.

The parameter control fields work similarly to the parameter controls available in Vault ACL policies. RAR parameter controls provide an additional layer of restriction on top of policy-level controls, enabling fine-grained authorization directly within OAuth tokens.

Templated paths

RAR path fields support the same identity template syntax as ACL policy paths. When Vault evaluates an authorization_details claim, it resolves {{...}} placeholders in each path using the identity information for the authenticated entity identity.

RAR paths support all template parameters available in ACL policies. Refer to the templated policies parameter reference for the full list.

Be aware of the following considerations when using templates:

Vault returns a "permission denied" response when the rendered output of an identity template includes wildcards (+) or globs (*).
Use IDs wherever possible. Each ID is unique and stable, whereas names can be reused and change over time.

The following authorization_details object uses the same {{identity.entity.id}} template you might use in an ACL policy to restrict the JWT to the KVv2 plugin path associated with the authenticated entity:

{
  "authorization_details": [
    {
      "type": "vault:path_access",
      "path": "secret/data/users/{{identity.entity.id}}",
      "capabilities": ["read"]
    }
  ]
}

When Vault evaluates the authorization constraint, it replaces {{identity.entity.id}} with the actual entity ID (for example, abc123) and checks whether the request path secret/data/users/abc123 is permitted. The ACL policy must independently allow the entity access to the target path for the request to succeed.

Unresolvable templates

If Vault cannot resolve a template placeholder, it silently skips that authorization_details entry. If no other entries match the request, Vault denies the request with a permission denied error.

The fact that Vault skips unmatched placeholders means you can include a templated constraint alongside a static fallback without causing an error when Vault cannot resolve the template. For example, in the following authorization constrain, Vault skips the first, unresolvable entry and evaluates the second entry normally:

{
  "authorization_details": [
    {
      "type": "vault:path_access",
      "path": "secret/data/users/{{identity.entity.UNKNOWN}}",
      "capabilities": ["read"]
    },
    {
      "type": "vault:path_access",
      "path": "secret/data/users/fallback",
      "capabilities": ["read"]
    }
  ]
}

Basic RAR definition

The following constraint:

Applies to the path database/creds/my-role.
Permits only read operations.
Works with ACL policies to determine final access for the entity.

{
  "type": "vault:path_access",
  "path": "database/creds/my-role",
  "capabilities": ["read"]
}

Example RAR request with multiple constraints

A JWT can include multiple authorization detail objects in the authorization_details array. Vault evaluates each constraint independently. The JWT request succeeds if the authorization detail object matches at least one constraint that permits the operation and no matching constraint denies it.

{
  "authorization_details": [
    {
      "type": "vault:path_access",
      "path": "database/creds/readonly-role",
      "capabilities": ["read"]
    },
    {
      "type": "vault:path_access",
      "path": "pki/issue/my-role",
      "capabilities": ["create", "update"]
    }
  ]
}