PAR

Expanded Definition

Pushed Authorization Requests, or PAR, are an OAuth 2.0 security extension that moves authorisation request parameters from the browser front channel to a direct back-channel submission to the authorisation server. The browser then carries only a reference to the stored request, which reduces tampering and leakage of sensitive parameters. This matters in NHI and machine-to-machine flows because clients often rely on tightly scoped, pre-approved request context.

PAR is commonly discussed alongside OAuth security hardening, but its role is narrower than general token protection. It does not replace client authentication, consent handling, PKCE, or token audience controls. Instead, it strengthens request integrity before the redirect occurs, which is especially valuable where redirect URIs, scopes, or policy signals are likely to be modified in transit. The IETF standard for this pattern is defined in RFC 9126, while broader identity governance expectations are often framed through the NIST Cybersecurity Framework 2.0.

Definitions vary across vendors when PAR is bundled with other OAuth hardening features, so practitioners should treat it as a request-integrity control rather than a complete authorisation model. The most common misapplication is assuming PAR alone prevents authorisation abuse, which occurs when organisations leave weak client authentication or loose redirect validation unchanged.

Examples and Use Cases

Implementing PAR rigorously often introduces an extra protocol round trip and tighter authorisation-server coordination, requiring organisations to weigh stronger request integrity against some added implementation complexity.

• A service account initiates an OAuth flow for an internal agent, and PAR ensures the requested scopes are committed before the browser redirect can be altered.
• An API client uses PAR with PKCE so the request object and code verifier together reduce interception and tampering risk.
• A platform team handling high-value secrets adopts PAR to protect dynamic request parameters that influence downstream token issuance and policy decisions.
• An organisation reviewing NHI exposure uses the Ultimate Guide to NHIs as a governance reference while mapping where OAuth request integrity fits into broader service-account controls.
• A federated workload identity design combines PAR with a strict redirect allowlist and server-side request validation so front-channel manipulation cannot widen access.

Because PAR is an OAuth extension, its strongest use cases appear where browser-mediated redirects remain necessary but request parameters must not be exposed to client-side tampering. It is especially useful in high-assurance integrations that carry privileged scopes, automation credentials, or agent execution paths.

Why It Matters in NHI Security

PAR matters because NHI abuse often begins with small compromises in request handling, not only with stolen credentials. If an attacker can alter scopes, redirect destinations, or policy inputs before the authorisation server sees them, the resulting token may be valid but overbroad. That is exactly the kind of pathway that turns routine OAuth usage into a privilege-escalation event. NHI Mgmt Group notes that 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, which underscores how often identity failures become operational incidents rather than theoretical weaknesses.

PAR does not remove the need for strong lifecycle controls, scope design, or least privilege. It simply removes one common tampering path at the authorisation boundary and makes downstream policy enforcement more trustworthy. In NHI programs, that is valuable because service accounts and agents are often granted automation privileges that can amplify even minor request manipulation. Security teams should pair PAR with redirect validation, client authentication, and token governance so the control is not treated as a standalone safeguard. Organisations typically encounter the need for PAR after an OAuth flow is abused to mint an overprivileged token, at which point request integrity becomes operationally unavoidable to address.