PAR
Pushed Authorization Requests (RFC 9126). The client sends authorization parameters directly to the server over a back channel first, hardening the flow against tampering. Required by stricter profiles like FAPI.
PAR removes the front channel as a tampering surface: instead of packing scope, redirect URI, and request parameters into a browser URL where they can be modified or logged, the client registers them server to server and passes an opaque reference. It also gets around URL length limits for rich authorization requests. Mandatory in FAPI, and a sensible default for anything high value.
See also: OAuth 2.0, FAPI, authorization code flow, PKCE
Related on Start with Identity
- GlossaryDevice Authorization Grant
An OAuth 2.0 flow (RFC 8628) for input-constrained devices like TVs and CLIs. The user authorizes on a second device using a short code. Device code flow is the
- GlossaryClient Credentials Grant
An OAuth 2.0 flow where an application authenticates as itself, with no user present, to obtain an access token. The standard pattern for machine-to-machine acc
- GlossaryOpenID Connect (OIDC)
OpenID Connect is an authentication layer built on top of OAuth 2.0. Where OAuth tells you what a token is authorized for, OIDC tells you who the user is via a
- CVEDrupal Simple OAuth/OIDC auth bypass via an alternate path
Drupal Simple OAuth / OIDC 6.0.0 through 6.0.6 allowed authentication to be skipped on an alternate path. Patched in 6.0.7.
- CVEDuende OAuth token management mixes tokens across requests
A race in Duende's .NET OAuth token-management package could attach client A's token to client B's request. Session mix-up, not a crypto break, but it is still
- CVEKeycloak client policy enforcement flaw
A 2026 Keycloak client-policy enforcement bug. Client policies are how you ban implicit flow, require PKCE, or force FAPI. If they do not fire, the realm's writ