An authorization request asks a precise, contextual question: may a principal perform an action on a resource now? It gives a policy engine the facts needed to make an access decision instead of relying on a sign-in, role, or network location alone. The response may be allow or deny and can identify the policies that influenced the result. section 4.3.2 section 4.4.1
Most requests follow PARC: Principal, Action, Resource, and Context. A principal can be a person, service, delegated role, or agent; context captures runtime facts such as device trust, time, location, tenant, or risk signals. Policies match request scope against principal, action, and resource, then evaluate conditions against context. section 7.3 section 7.3.1
Construct a dependable request at the enforcement boundary:
- Verify the caller’s identity and preserve the initiating principal rather than substituting the authority of an intermediary service. section 13.4 section 11.1.1
- Derive a stable action from the API route or function, identify the target resource by canonical ID, and collect only relevant runtime context. section 7.3.1 section 13.4
- Normalize the facts into a common structure and send them to the policy decision point for consistent evaluation and centralized logging. section 13.2 section 13.4.3
- Enforce the returned decision before protected processing; do not treat a service’s own access as proof that the initiating principal is authorized. section 11.1.1 section 18.3
Manager salary lookup
A dashboard request to view department salaries identifies Carol as principal, view_salaries as action, her department as resource, and the calling dashboard as context. A gateway evaluates that request before reaching the HR API: Carol may view her own department’s salaries, while a request for another department is denied. The same structure prevents the dashboard from acting as a confused deputy. section 11.1.1
{
"principal": "Employee::\"bob\"",
"action": "Action::\"edit\"",
"resource": "Document::\"doc456\"",
"context": {
"device": {
"is_managed": true
},
"time": "2025-07-08T10:30:00Z"
}
}
A JSON request makes PARC concrete: Bob requests document editing from a managed device at a specified time. The structured shape separates policy input from the HTTP, gRPC, token, and application data used to assemble it. section 7.3.1
Authorization requests support continuous, contextual decisions across APIs, tenant systems, and agent tool calls. In layered architectures, one normalized request can be evaluated first against platform governance policies and then against tenant collaboration policies; each enforcement point records and applies its own result. section 13.4.3 section 15.2 section 18.3
