Why We Prefer Signed Authorization Requests

Signed authorization requests are the single most important design point in OIDC Web. The reasoning follows directly from what makes the product different.

In a conventional identity provider, starting a login is cheap — the provider just renders a password form. In OIDC Web, starting a login is expensive. Every authorization request that reaches the verification stage consumes a real iProov verification credit and counts against a rate-limited API allowance. The verification is the product.

That cost changes the threat model. Consider an unsigned authorization request — an ordinary OIDC authorization URL with the parameters in the query string. Anyone who can see or guess the URL can copy it, modify its parameters, and replay it any number of times.

A forged request cannot produce a valid login; no attacker can pass a live verification on someone else's behalf. But the forged request does not need to succeed. Simply by arriving, a flood of forged or replayed authorization URLs can:

• burn verification credits that you are billed for,
• exhaust your rate-limit allowance, and
• deny service to your genuine users by saturating that allowance.

The fix is to make authorization requests integrity-protected and bound to your registered application. Tampered or forged requests are then rejected before any verification resource is spent. OIDC Web supports two standard, complementary mechanisms:

• Signed authorization requests (JAR, RFC 9101) — the request parameters are carried inside a JSON Web Token (JWT) signed by your application's key. OIDC Web verifies the signature against the public key registered for your client and rejects anything that does not match. See JAR.
• Pushed Authorization Requests (PAR, RFC 9126) — your application pushes the request to OIDC Web over an authenticated back channel and receives an opaque, single-use request_uri to put in the browser URL. The real parameters never appear in a user-visible, tamperable URL. See PAR.

OIDC Web supports unsigned authorization requests for compatibility. We strongly advise every production integration to use signed requests (JAR), ideally combined with PAR. Signed flows protect your service and your bill from forged and replayed authorization requests. Clients can be configured to require signed requests; we recommend that for any production deployment.