Auth regression
Run multiple validation checks in one request and aggregate them into a suite result.
Batch validator. Each check runs through the same logic as /v1/validate/jwt and returns a VerifyResult; the suite is then judged by fail_on_severity. Designed to run in CI alongside fixture tokens that capture known-good and known-bad cases.
Request
| Field | Type | Required | Description |
|---|---|---|---|
| checks | Check[] | yes | List of validation checks. Minimum length 1. |
| fail_on_severity | "error" | "warning" | null | no | Severity threshold for the suite result. "error" (default behaviour when omitted) marks the suite failed if any check has an error finding. "warning" additionally fails on warnings. |
Check
| Field | Type | Required | Description |
|---|---|---|---|
| token | string | yes | JWT to validate. |
| policy | VerifyPolicy | no | Inline policy. See VerifyPolicy. Mutually exclusive with issuer_profile_id. |
| issuer_profile_id | string | no | Registered profile ID. Mutually exclusive with policy. |
| expected_failure_codes | string[] | no | Codes that must appear in findings[].code for the check to count as expected. Use this for negative fixtures (e.g. an expired token expected to fail with TOKEN_EXPIRED). |
A check whose findings contains every code listed in expected_failure_codes is treated as passed for suite purposes — the failure was the expected outcome. Use this to assert that misconfigurations stay broken.
Response — 200
| Field | Type | Required | Description |
|---|---|---|---|
| suite_status | "pass" | "fail" | yes | "pass" when every check matched expectations and the threshold isn't crossed; "fail" otherwise. |
| passed | integer | yes | Number of checks that satisfied their expectation (valid, or invalid with the expected codes). |
| failed | integer | yes | Number of checks that did not. |
| results | VerifyResult[] | yes | Per-check results in the same shape as /v1/validate/jwt. |
| fail_on_severity | "error" | "warning" | null | yes | Echo of the request parameter for caller visibility. |
| request_id | string | yes | Unique ID propagated to the audit log. Useful when correlating CI runs with server-side traces. |
{
"suite_status": "pass",
"passed": 2,
"failed": 0,
"fail_on_severity": "error",
"request_id": "req_01HK92T8QYA7ZMFJXC3",
"results": [
{
"valid": true,
"statuses": {
"signature": "pass",
"issuer": "pass",
"audience": "pass",
"algorithm": "pass",
"time": "pass",
"required_claims": "pass"
},
"findings": [],
"summary": "Token is valid: signature verified, issuer/audience/time/required-claims all passed.",
"metadata": {}
},
{
"valid": false,
"statuses": {
"signature": "pass",
"issuer": "pass",
"audience": "pass",
"algorithm": "pass",
"time": "fail",
"required_claims": "pass"
},
"findings": [
{
"code": "TOKEN_EXPIRED",
"severity": "error",
"message": "Token expired at 2024-12-01T00:00:00Z.",
"evidence": {
"exp": 1733011200,
"now": 1761499200
}
}
],
"summary": "Token is NOT valid: token expired.",
"metadata": {}
}
]
}Errors
| Channel | Code | Cause |
|---|---|---|
| 400 | MALFORMED_TOKEN | A check’s token is not parseable. |
200, in results[i].findings | (validation codes) | Same set as /v1/validate/jwt. |
| 422 | — | checks empty, or a check has both/neither policy and issuer_profile_id. |
Use case — fixture-driven CI
Commit fixture tokens to your repository (positive tokens issued under a stable test key, negative tokens with deliberate misconfigurations). On every CI run, POST them to /v1/test/auth-regression to confirm:
- Tokens that should validate still do (catches policy drift, key rotation issues).
- Tokens that should fail still fail with the same codes (catches accidental relaxations).
See CI · OIDC guide for a complete CI integration including this endpoint.