> ## Documentation Index
> Fetch the complete documentation index at: https://docs.runlayer.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Connector OAuth Clients

> Control which OAuth clients can connect to a connector: pre-registered clients with fixed credentials, and per-connector switches for self-registered (DCR and CIMD) clients.

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

| Kind                                    | How the client gets credentials                                                                                                                                                                           | Who controls it |
| --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- |
| **Pre-registered**                      | An admin creates it on the Clients tab. Runlayer issues a fixed `client_id` and `client_secret`.                                                                                                          | Admin           |
| **Dynamic client registration (DCR)**   | The client registers itself at `/oauth/register` ([RFC 7591](https://datatracker.ietf.org/doc/html/rfc7591)) the first time it connects. Most desktop and IDE clients (Claude, Cursor, VS Code) use this. | Client          |
| **Client ID metadata documents (CIMD)** | The client's `client_id` is an HTTPS URL pointing at a metadata document it hosts. No registration call.                                                                                                  | Client          |

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.

<Warning>
  The client secret is shown **once**. Copy it before closing the dialog. You can regenerate it later, but you cannot view it again.
</Warning>

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.

<Note>
  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.
</Note>

## Audit trail

Every action on this tab is recorded in **Audit Logs**:

| Action                                 | Event                               |
| -------------------------------------- | ----------------------------------- |
| Create pre-registered client           | `Proxy OAuth Client Registered`     |
| Edit name or redirect URIs             | `Proxy OAuth Client Updated`        |
| Regenerate secret                      | `Proxy OAuth Client Secret Rotated` |
| Revoke                                 | `Proxy OAuth Client Revoked`        |
| Client denied by a registration switch | `Proxy OAuth Authorization Failed`  |

## Related

* [Connecting AI Clients](/connecting-clients) — choosing between the unified Runlayer Plugin endpoint and per-connector endpoints
* [MCP Security Best Practices](/mcp-security-best-practices)