Workspace OAuth clients
این محتوا هنوز به زبان شما در دسترس نیست.
Settings → Developers → MCP OAuth Clients — create and manage workspace OAuth clients for the public Entergram MCP gateway.
Workspace admin access required. Only workspace owners and admins can manage shared MCP OAuth clients.
Workspace vs personal
Section titled “Workspace vs personal”Workspace clients support both public PKCE clients and confidential clients with
client_secret_postorclient_secret_basic. Keep shared integrations here, and use the personal clients section for your own seat-scoped agents.
Members don’t see workspace clients directly — they exist for team-wide automation.
Creating a client
Section titled “Creating a client”Create client — register a workspace OAuth client that can authorize against the Entergram MCP gateway.
| Field | Notes |
|---|---|
| Client name | e.g. Entergram Workspace Agent |
| Platform | Pick one, or Custom |
| Token endpoint auth | Public (none), or Confidential (client_secret_post / client_secret_basic) |
| Require PKCE | Mandatory for public clients; recommended for confidential ones as extra protection |
| Description | Short explanation shown on the consent screen |
| Redirect URIs | One per line. HTTPS required outside localhost |
| Allowed scopes | These scopes limit what the workspace client can request during authorization |
Use
nonefor local PKCE clients. Useclient_secret_*for hosted or server-side integrations.
Workspace clients can request the full scope set — see the scope table in MCP connectors.
The client secret
Section titled “The client secret”Confidential clients get a secret shown once:
One-time reveal — Entergram stores only a hash of this secret. After closing this dialog, you will only be able to rotate it, not reveal it again.
Public clients get no secret and must authenticate with PKCE.
Managing clients
Section titled “Managing clients”The list shows Active clients and Total clients, and per client:
- Public client / Confidential client, PKCE on / PKCE off
- Created, Created by, Last used, Last used by
- Active grants
- Expandable Client details — Client ID, auth method, secret preview, PKCE requirement, and a Ban reason where applicable
| Action | Effect |
|---|---|
| Edit | Change name, scopes, redirect URIs |
| Disable | Stops new authorizations and token refreshes until re-enabled |
| Enable | Re-allows authorization and refresh |
| Rotate secret | Issues a new secret, shown once; the old one stops working |
| Archive | ”Archiving disables the client and revokes active grants and refresh tokens for this workspace client.” |
Empty state: “Create the first shared MCP OAuth client for this workspace.”
Choosing between disable, rotate and archive
Section titled “Choosing between disable, rotate and archive”| Situation | Action |
|---|---|
| Temporarily pausing an integration | Disable |
| Secret may have leaked | Rotate secret (immediately) |
| Integration is retired | Archive |
| You’re mid-incident and unsure | Archive — it revokes grants and refresh tokens too |
Operating notes
Section titled “Operating notes”- Name clients after the system, not the person. Zapier CRM bridge survives the person who set it up leaving.
- Grant the narrowest scope set that makes the integration work. You can always widen it.
- Review Last used quarterly. A client with no recent use and active grants is exactly the kind of thing that gets exploited quietly.
- Client lifecycle events are recorded in the activity log.
- Deleting the workspace removes its connectors and API keys along with it.
Related
Section titled “Related”Cookie preferences
We respect your right to privacy. Choose which cookies to allow — your choice applies across our site. Cookie Policy
Required for the site to work, including remembering your privacy choices. Always on.
Help us understand which pages are popular and how visitors use the site.