Skip to content

The v1 docs follow nauthera-server's main branch and its 0.x releases on the way to 1.0, so fields and APIs can still change.

v1

invalid_request_object

Docs version v1 (main)Nauthera is pre-1.0, in a design-partner program

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 · Generated from internal/runbook/oauth.yaml in nauthera-server.