Can remote_json authorizer evaluate allow/deny based on a response body field (not only HTTP 403)?

[jjhwan-h]

Background

We use the remote_json authorizer to delegate authorization decisions to an external authorization service.
Some authorization services always return 200 OK with a JSON body (e.g., {"result": true|false}) and do not signal allow/deny via status codes.

Current behavior

remote_json determines the decision solely from the upstream HTTP status code.

200 OK → allow

403 Forbidden → deny

Therefore, with services that follow the “200 + body value” pattern, direct integration is difficult without a middle adapter.

Request

Please add an option to derive allow/deny from a specific field in the response body.

Example: Using JSONPath/template, allow if $.result == true, otherwise deny

Optionally, allow mapping extra fields like reason/headers to control error messages/headers.

Example (reference) — External auth service(e.g. OPA) that only changes the body, not the status code

POST /decision
Content-Type: application/json

{ "input": { "subject": "u1", "action": "read", "resource": "/orders/123" } }

Allow response:

200 OK
{ "result": true, "reason": "ok" }

Deny response:

200 OK
{ "result": false, "reason": "not_owner" }

[vinckr]

Hello @jjhwan-h

you are right decision logic relies exclusively on HTTP status codes (200/403).

some questions on this proposal:

1. Should field mapping support only boolean checks, or also string enums ("allow"/"deny") or numeric codes?
2. If reason field is present, should it override Oathkeeper's default error message, or append to it?
3. Does your external service return machine-readable error types (e.g., "error_code": "insufficient_permissions") that could map to specific HTTP status/headers downstream?

assumptions to validate

1. Error handling: What happens if:
   1. Response body is malformed JSON?
   2. Specified JSONPath doesn't exist ($.result missing)?
   3. Field exists but value is neither true nor false (e.g., "allowed")?
2. Precedence: If both status code (403) and body field ($.result: true) signal conflicting decisions, which wins?
3. Performance: Does parsing/evaluating JSONPath for every authz request introduce measurable latency compared to status-only checks?
4. Security: Can an attacker exploit JSONPath injection if path configuration is partially user-controlled? (Unlikely, but validate.)