# invalid_request_object

The signed request object is malformed, unverifiable or invalid (RFC 9101 §6.3).

## Meaning

Sent by `/par` when the `request` parameter fails verification: it is not a well-formed
JWS, uses an algorithm the organization does not accept, names a `kid` the client's
key set does not hold, has a bad signature, the wrong `aud` or `iss`, has expired or is
not yet valid, or the client registered no key set (no `jwks_uri` and no `jwks`). At
`/authorize` the same failures are a direct refusal and show only `invalid_request`.

## Impact

The client cannot start a sign-in until its request objects verify. Usually a key
rotation the client's `jwks_uri` does not reflect, or clock skew.

## Diagnosis

1. The audit record under `oauth.authorization.requested` has reason
   `invalid_request_object` and a cause: `request_object_malformed`,
   `request_object_alg_not_allowed`, `request_object_kid_unknown`,
   `request_object_signature_invalid`, `request_object_aud_mismatch`,
   `request_object_iss_mismatch`, `request_object_expired`,
   `request_object_not_yet_valid` or `jwks_uri_missing`. It also records the object's
   `alg` and `kid`.
2. Fetch the client's `jwks_uri`, or read its registered `jwks`, and confirm it holds the
   `kid` the object names.

## Mitigation

- As a client developer: sign with a key your key set holds, set `aud` to the
  issuer and `iss` to your client id, keep `exp` short, and keep your clock in sync.
- As an operator: confirm the client's registered `jwks_uri` is reachable from the
  server.
- As a user: tell the application's owner.

## Escalation

If an object that verifies against the published key is refused, open an issue with the
request id, the server version and the recorded cause. Never attach the request object.

---

[OAuth error runbooks](https://www.nauthera.io/docs/v1/runbooks/oauth) · Generated from [`internal/runbook/oauth.yaml`](https://github.com/nauthera/nauthera-server/blob/main/internal/runbook/oauth.yaml) in nauthera-server.