Skip to content

OAuth Clients (Administration)

As an administrator, the OAuth Clients page lists every third-party application that has registered itself against your OctoPerf instance's bundled OAuth Identity Provider. These are the clients your users authorize through the OAuth flow when they connect an AI agent to the OctoPerf MCP server - typically Claude.ai Custom Connectors, Claude Code, Cursor, Continue.dev, ...

OAuth Clients admin table

Why This Matters

Where the per-user Connected Apps page shows which connectors a user authorized, this admin page shows which connectors exist on the platform at all. The two views answer different questions:

  • Audit the OAuth client population: verify only expected clients are registered (every Claude.ai workspace creates its own DCR entry, for instance).
  • Investigate a compromise: if a client looks suspicious, you can delete it and force every user grant tied to it to fail on the next call.
  • Clean up after pilots / migrations: remove abandoned DCR registrations that nobody uses anymore.
  • Cross-check the IdP wiring: if no clients ever show up here, your reverse-proxy is likely stripping /auth/connect/register.

Dynamic Client Registration (DCR)

The MCP server accepts anonymous Dynamic Client Registration per RFC 7591 at POST /auth/connect/register. This is what lets a Claude.ai Custom Connector or an MCP Inspector boot strap itself against your OctoPerf instance without any pre-shared client id / secret: the agent posts its metadata (name, redirect URIs, scopes, grant types) and the IdP mints a client id on the fly. The resulting registration shows up in this table.

This is the default OAuth posture for the OctoPerf MCP integration. Administrators normally do not add OAuth clients by hand - the page is read-only for the common case, used for audit, inspection, and cleanup.

Understanding the Information

For each registered client, the table shows:

  • Client: the human-readable clientName the agent registered with. Hovering shows the underlying clientId.
  • Redirect URIs: the URLs the IdP is allowed to redirect to after a successful login. Inspect this carefully when investigating: a client redirecting to an unexpected host is a red flag.
  • Scopes: the OAuth scopes the client registered for. Recorded for audit purposes - the MCP server does not currently enforce per-scope checks, so this column is informational.
  • Grant Types: typically authorization_code plus refresh_token.
  • Created: the clientIdIssuedAt timestamp; when the DCR registration was minted.

The table supports filters at the top so you can narrow down a large registration set by name, redirect URI, or grant type.

Inspecting a Client

Click Inspect (or click the row directly) to open the inspection dialog. It has two sections:

Inspect OAuth Client dialog

Client definition

A read-only JSON view of the full RFC 7591 client metadata as stored on the IdP - including fields not surfaced in the table (e.g. tokenEndpointAuthMethod, policyUri, tosUri when the client provided them). This is what you'd hand a support ticket if a user reports an OAuth failure with a specific client.

Connected users

A paginated table of every active user grant against this OAuth client:

  • User: username (with userId shown on hover).
  • Scopes: the scopes recorded against this grant (informational - not enforced).
  • Last activity: last refresh-token use or tool call.
  • Expires at: refresh-token expiry date.

Click Revoke on any row to invalidate just that user's grant. The user's agent will fail on the next tool call and have to redo the OAuth flow. Other users connected through the same client are unaffected.

This is the right action when a specific user reports a stuck or compromised connector but the OAuth client itself is legitimate.

Deleting an OAuth Client

From the row's secondary menu (the three-dot menu), choose Delete to remove the entire client registration. This is heavier than per-user revocation:

  • All grants tied to the deleted client become invalid immediately.
  • The client is removed from the IdP's allow-list - any agent still holding a refresh token for it fails on next use.
  • Re-installing the connector on the client side will re-register through DCR and produce a new clientId; users will have to log in again to re-establish their grant.

Use Delete when:

  • The client is unknown / unexpected and you want to cut it off entirely.
  • A vendor pushed a breaking change to its registered metadata and you want every user's grant reset against the new entry.
  • You're cleaning up after a test deployment.