Skip to main content

Run the protection test

The Test tab is a single button that tells you whether the setup so far is internally consistent. It's not a runtime exercise — it's a pre-flight check.

What the UI does​

One button: Run test. Click it → calls POST /authsec/resource-servers/:id/test-login → renders the response.

The response is JSON shaped like:

{
  "resource_server": { "id": "...", "state": "needs_setup", "scan_generation": 1 },
  "oauth": {
    "state": "ready",
    "ready_since": "2025-10-30T14:22:13Z"
  },
  "sdk_enforcement": {
    "sdk_policy_state": "compiled",
    "tool_count": 101,
    "unmapped_tools": 96
  }
}

What it actually checks​

Three things, all read-only:

  1. OAuth readiness. Is Hydra (the upstream OAuth provider) up and reachable? Are the client credentials for this resource server provisioned? This catches setup problems before tokens are needed.
  2. SDK policy state. Has the mcp_tool_scope_maps table been compiled into a coherent scope matrix? This catches half-mapped states (e.g. a scope was deleted but tools still point at it).
  3. Tool inventory counts. Tool count and unmapped count — same numbers shown in the activation preview on the Launch tab. This is the headline check: if unmapped_tools > 0, you can't activate yet.

What it does NOT do​

This is important enough to call out explicitly. The Test tab is not:

  • An end-to-end OAuth flow runner. It doesn't acquire a token.
  • A per-user, per-client, per-tool simulator. It can't answer "would Alice with client Claude-Desktop be allowed to call create_pr?" — that requires a backend endpoint that doesn't exist yet.
  • A live call against your MCP server. It doesn't hit your /mcp URL with a test token.
  • A latency or throughput probe. There's no perf data here.

If you want a real end-to-end exercise, the first-run guide step 10 shows the three-curl loop (401, 403, 200) that proves it actually works. That's the runtime check; this tab is the setup check.

When to run it​

  • Before clicking Activate. Final sanity check; if anything's red here, the Launch tab's checklist will already tell you.
  • After making non-trivial scope or mapping changes. Catches the case where you deleted a scope but tools still reference it.
  • After rotating the introspection secret. Confirms the new credentials are in use.

Safe to re-run any time. No side effects.

What "OAuth state: ready" means​

The OAuth subsystem (Hydra) is provisioned for this resource server, the introspection client credentials are valid, and the JWKS endpoint returns keys. If this is not ready, your SDK will fail validation on every token.

What "SDK policy state: compiled" means​

The current scope matrix is consistent: every active tool-scope mapping points at a scope that exists, and the access policy points at a role that exists. If this fails, fix the underlying inconsistency (usually a deleted scope or role still referenced somewhere) before activating.

Coming later​

The plan tracks two missing endpoints honestly:

  • Per-scenario simulation. POST /authsec/resource-servers/:id/simulate-access with {user_id, client_id, requested_scopes, tool_name} → {granted_scopes, denied_scopes, reason}. Useful for debugging "why can't user X call tool Y?"
  • End-to-end live probe. Acquire a token, call a live tool, report 200/403/401 with timing.

Both are on the roadmap; this page will get updated when they ship.

Auth scheme​

POST /authsec/resource-servers/:id/test-login requires admin JWT. Not an SDK-facing endpoint.