Skip to content
Veraproof Veraproof Docs

Responder

Responder

The Responder page is Challenge’s analyst-facing incident response console. From a single form you can create identity verification challenges or revoke user sessions across configured session revocation connectors.

Use Responder both for live incidents and to validate new app connectors during setup before you enable MCP or webhook automations.

Access

  1. Log in at challenge.veraproof.io.
  2. Select Responder in the main navigation.

Who can do what

RoleOpen ResponderSubmit actions (create challenge / revoke sessions)
OwnerYesYes
AdminYesYes
AnalystYesYes
ViewerYes (read-only)No

Viewer users see the form and connector options for awareness but cannot click Execute. Assign the Analyst role (or higher) to operators who should run incident response from the UI. See User Management for role assignment.

Owners on trial tenants need a payment method on file before Responder and integrations are available. Session revocation also requires Session Revocation to be enabled under Integrations.

Execute an action

Common fields

FieldDescription
UsernameEmail or UPN for challenges and revocations (see connector-specific formats in Session Revocation Integration).
ActionRevoke sessions or Create challenge.
Reason / contextOptional text stored on the request or challenge for auditing.

Revoke sessions

  1. Choose Revoke sessions as the action.
  2. Enter the target user’s email or UPN.
  3. Under Session revocation targets, leave all boxes unchecked to run against every enabled connector, or check only the apps you want to test (for example, only Okta while validating Okta credentials).
  4. Click Execute.

The UI submits the request and polls for completion. The Result panel shows JSON including per-connector outcomes (revoked, user_not_found, failed, and error details).

Verify results on the Dashboard under Session revocations or the combined Activity feed.

Create challenge

  1. Choose Create challenge as the action.
  2. Enter the target username (email recommended for delivery).
  3. Select Delivery method: Slack workspace or Webhook integration.
  4. Choose an Integration instance configured on the Integrations page.
  5. Click Execute.

On success you receive a challenge_id and verification_url in the result JSON. The challenge appears on the Dashboard like any other challenge.

Slack requester fallback in Responder

When you create a Slack challenge from Responder, Challenge first tries to use the signed-in operator as the requester (via their email mapped to a Slack user in that workspace).

  • If the operator exists in that Slack workspace, that user is shown as the requester.
  • If the operator does not exist in that Slack workspace, Challenge falls back to the Slack app bot user as the requester so the challenge can still be delivered.

This fallback is specific to Responder’s Slack delivery flow and helps mixed environments where analysts may not be provisioned in every connected Slack workspace.

Testing a new session connector

Recommended workflow when onboarding Okta, Entra, Google Workspace, Slack Enterprise, or Miro:

  1. Configure the connector on Integrations → Session Revocation (domain, token, enable checkbox, save).
  2. Enable session revocation at the tenant level if it is not already on.
  3. Open Responder and use a dedicated test user in each target system (not a production executive account).
  4. Sign that user into the target app in a browser or client so an active session exists.
  5. Run Revoke sessions with only the connector under test selected.
  6. Confirm in the result JSON:
    • Lookup succeeded (found semantics reflected in outcomes).
    • Revocation outcome is revoked or tokens_revoked (Entra).
  7. Confirm the user must sign in again in the target application.
  8. Check the Dashboard for a completed session revocation row (channel Admin UI).
  9. Repeat for the next connector, then test all enabled targets together.
  10. Enable MCP or webhook channels only after manual tests pass.

If the outcome is user_not_found, verify the username format for that connector (for example UPN for Entra, primary email for Google). If the outcome is failed, re-check API permissions in the connector guide.

Okta-specific test notes

When validating optional Okta settings:

  • Test once with default options (sessions only).
  • If you enabled Revoke OAuth/OIDC tokens or Forget remembered devices, run a second test and confirm the extra behavior matches your policy. See Okta optional settings and Okta User Sessions API.

Billing note

Each completed session revocation request from Responder counts as one metered usage event, combined with challenges toward your tier limit. Failed requests are not billed. See Billing & Subscription Management.

Best practices

  • Use separate test accounts per environment; revoking sessions disrupts active work.
  • Record a clear reason on every production revocation for audit trails.
  • Narrow integration targets during connector rollout; use all enabled targets only when you intend full containment.
  • After Responder tests succeed, mirror the same username and targets in MCP or webhook playbooks.

Support

For issues with Responder or connector testing, contact [email protected].