Skip to main content
Every AI client that connects to a Runlayer connector authenticates through Runlayer’s OAuth server. The Clients tab on a connector’s settings page lets admins decide which kinds of clients are allowed and manage the credentials Runlayer issues. Open it from Connectors → (connector) → Settings → Clients. Requires the Manage connectors permission.

​
Client kinds

Pre-registered clients are the right choice for software that needs stable OAuth credentials you configure once: a scheduled agent, an internal integration, or a vendor product that asks for a client ID and secret.

​
Pre-registered clients

​
Create

  1. On the Clients tab, click Create OAuth client.
  2. Enter a display name and one or more exact redirect URIs (one per line).
  3. Click Create client. Runlayer shows the client ID, client secret, and the authorization, token, and MCP URLs for this connector.
The client secret is shown once. Copy it before closing the dialog. You can regenerate it later, but you cannot view it again.
Pre-registered clients are confidential clients: they authenticate to the token endpoint with client_secret_post, use the authorization code grant with PKCE, and may refresh tokens. Each client is bound to one connector and one organization.

​
Edit

Use the row’s ⋯ → Edit to change the display name or redirect URIs. Redirect URIs are matched exactly. Removing a URI takes effect immediately, including for authorizations already in progress.

​
Regenerate secret

⋯ → Regenerate secret issues a new secret and shows it once. The old secret stops working immediately, and every token issued under it — refresh and access — is revoked, so users reconnect after you update the client’s configuration.

​
Revoke

⋯ → Revoke removes the client. This is immediate: the client can no longer authorize or refresh, and access tokens it already holds are rejected on their next request to the connector.

​
Client registration

The Client registration section has two switches:
  • Dynamic client registration (DCR)
  • Client ID metadata documents (CIMD)
Both are on by default. Changes are staged until you click Save changes. Turning a switch off revokes that client kind’s access to this connector:
  • New authorization requests from that kind of client are rejected with unauthorized_client.
  • Pending logins and token exchanges are rejected.
  • Refresh requests are rejected.
  • Access tokens already issued to that kind of client are rejected on their next request to the connector’s MCP endpoint.
These switches govern direct connections to the connector’s own MCP endpoint. They do not apply to access through a plugin, including Runlayer Plugin: a client connected to a plugin authenticates to the plugin, and each connector’s tools are then governed by that connector’s policies. Pre-registered clients are never affected by these switches. Turn both off to allow only pre-registered clients on a connector. Turning a switch back on lets that kind of client authorize again. Users reconnect from their client; Runlayer does not restore old sessions.
These switches are per connector. They do not disable Runlayer’s global /oauth/register endpoint, because a client registers before it names a target connector. Enforcement happens when the client asks to authorize against a specific connector.

​
Audit trail

Every action on this tab is recorded in Audit Logs: