@@ -71,7 +71,7 @@ Per-user upstream credentials require user sessions, while shared credentials co
 
 ## Where authentication is configured
 
-On a built server, the **Authentication** tab carries both halves of authentication in one place. So does the **Authentication** section of a tunneled server's **Settings** tab, described in the product as "Who may connect to this server and how they sign in. Changes take effect on new connections." Before an identity provider is attached, the section shows **Set up authentication**, which requires MCP clients to authenticate through an upstream identity provider before reaching the server. Once one is attached, the section shows the **Session length**, **Client access**, and **Remote Identity Providers** fields. [Gateways](/docs/ai-control-plane/mcp-gateway/gateway-endpoints) reuse the same section.
+On a built or tunneled server, the **Authentication** section of the **Settings** tab carries both halves of authentication in one place, described in the product as "Who may connect to this server and how they sign in. Changes take effect on new connections." Before an identity provider is attached, the section shows **Set up authentication**, which requires MCP clients to authenticate through an upstream identity provider before reaching the server. Once one is attached, the section shows the **Session length**, **Client access**, and **Remote Identity Providers** fields. [Gateways](/docs/ai-control-plane/mcp-gateway/gateway-endpoints) reuse the same section.
 
 A remote server splits the same settings across two sections of its **Settings** tab: the **Identity** section described above, and a **Sessions** section with **Session length** and **Client access**, which shows its controls once User Identity is configured. See [Session length and refresh](/docs/ai-control-plane/mcp-gateway/access/session-refresh) and [OAuth client registration](/docs/ai-control-plane/mcp-gateway/access/client-registration#client-access).
 
 
@@ -30,7 +30,7 @@ Per-user upstream credentials come from a remote identity provider: an OAuth aut
 
 On a remote server, select **User Identity** and pick the **Identity provider**, as described in [Picking an authentication model](/docs/ai-control-plane/mcp-gateway/access#picking-an-authentication-model).
 
-On a built server, open the **Authentication** tab. On a tunneled server or a gateway, open the **Authentication** section of the **Settings** tab. Find **Remote Identity Providers** and click **Attach Provider**. The sheet asks for two things:
+On a built server, a tunneled server, or a gateway, open the **Authentication** section of the **Settings** tab. Find **Remote Identity Providers** and click **Attach Provider**. The sheet asks for two things:
 
 - **Identity Provider**, described as the upstream OAuth authorization server the platform delegates to. Either select an existing provider or add a new one by issuer URL, which is validated by fetching its metadata.
 - **Session Client**, described as the OAuth client the platform registers and uses with this provider.
 
@@ -44,7 +44,7 @@ How clients identify themselves, what the registration endpoint accepts, how red
 
 ## The consent screen
 
-Consent is always shown. It is never skipped, even for a client that has connected before, because the prompt is what guards against one client being confused for another.
+Consent is shown on every authorization, even for a client that has connected before, because the prompt is what guards against one client being confused for another. The one exception is a server behind a [shared authorization server](#shared-authorization-servers), where an approval already given for the same client carries over.
 
 The screen names the client asking for access and the server it wants, shown as "**Client** is requesting access to the MCP server **slug**". When the upstream publishes RFC 9728 protected-resource metadata, the card also shows the resource's own name and its **Documentation**, **Policy**, and **Terms** links, falling back to the authorization server's metadata when the resource advertises none.
 
@@ -67,6 +67,16 @@ When tool filtering on consent screens is turned on for the organization, people
 
 An organization admin turns this on from the **MCP Sessions** page under **Identity**. Changing it requires the `org:admin` scope. See [Organization-wide view](/docs/ai-control-plane/mcp-gateway/access/clients-and-sessions#organization-wide-view).
 
+## Shared authorization servers
+
+By default, every MCP server is its own authorization server. A client registers with each server separately, and a person approves each one on its own consent screen. When an organization runs many servers, people end up approving the same client over and over.
+
+A shared authorization server serves several MCP servers from one issuer URL. When a person has already approved a client for one server under that issuer, connecting the same client to another of its servers skips the consent screen. The screen still appears when the new server needs something the person hasn't approved, such as an upstream service to connect. Only the approval is shared: each server still gets its own tokens, its own tool selection, and its own [team access](/docs/ai-control-plane/mcp-gateway/access/team-access) rules, and revoking a session works per server as before.
+
+Organization admins can see each authorization server's mode and issuer URL on the **Speakeasy authorization servers** page in organization settings. Copy the issuer URL from there when an identity provider such as Okta asks for the authorization server.
+
+Moving an existing MCP server to a different authorization server makes every client connected to it authorize again. The dashboard warns before saving that change, so plan it for a time when re-authorizing won't interrupt people.
+
 ## Token lifetimes
 
 Access tokens last one hour, and that value is not configurable. When the sign-in's **Session length** deadline is less than an hour away, the access token expires at the deadline instead. Refreshing never extends the sign-in past that deadline, which is fixed when the person approves access. See [Session length](/docs/ai-control-plane/mcp-gateway/access/session-refresh#session-length).
 
@@ -112,7 +112,7 @@ Environment values reach a function through the MCP server that exposes it. Firs
 Then attach it to the server:
 
 - Go to [**MCP Gateway > MCP**](https://ai.speakeasy.com/@self/projects/default/mcp) and open the MCP server built from the function.
-- Open the server's **Authentication** tab. The **Environment Variables** section shows which environment is attached, or **No environment attached**.
+- Open the server's **Settings** tab. The **Environment Variables** section shows which environment is attached, or **No environment attached**.
 - Select the environment created in the first step. Each variable can be set to **System** (read from the attached environment), **User Provided** (set at runtime by the connecting client), or **Omitted**.
 
 These environment values now apply to every caller of the server. Values are resolved in layers, described in [Upstream credentials](/docs/ai-control-plane/mcp-gateway/access/upstream-credentials#environment-variables-on-built-servers).
 
@@ -97,7 +97,7 @@ Open the new server from the **MCP Servers** tab and use its **Tools** tab to re
 
 ## Step 3: Set environment variables
 
-If the API requires authentication, the server needs credentials. Go to [**MCP Gateway > Environments**](https://ai.speakeasy.com/@self/projects/default/environments), open or create an environment, and use **Fill for MCP Server** to prefill placeholder entries for everything the server needs; fill in the values and save. Then attach the environment to the server from the server's **Authentication** tab. See [Environments](/docs/ai-control-plane/mcp-gateway/environments) and [Upstream credentials](/docs/ai-control-plane/mcp-gateway/access/upstream-credentials) for how the values reach the API.
+If the API requires authentication, the server needs credentials. Go to [**MCP Gateway > Environments**](https://ai.speakeasy.com/@self/projects/default/environments), open or create an environment, and use **Fill for MCP Server** to prefill placeholder entries for everything the server needs; fill in the values and save. Then attach the environment to the server from the **Environment Variables** section of the server's **Settings** tab. See [Environments](/docs/ai-control-plane/mcp-gateway/environments) and [Upstream credentials](/docs/ai-control-plane/mcp-gateway/access/upstream-credentials) for how the values reach the API.
 
 <Callout title="Variable names" type="info">
   Generated variable names derive from the API name given in step 1. Not every prefilled variable is required. For example, a server URL variable is unnecessary when the spec already defines the server URL.
 
@@ -13,7 +13,7 @@ Starting March 2025, the MCP specification recommends OAuth-based authentication
 - **Client Credentials Flow**: For server-to-server authentication
 - **User-facing OAuth Flow**: For scenarios requiring dynamic user authentication
 
-The Speakeasy AI Control Plane exposes a variety of different options for OAuth that can be integrated into built MCP servers. These are configured on the **Authentication** tab of a built server, reached from [**MCP Gateway > MCP**](https://ai.speakeasy.com/@self/projects/default/mcp) in the project sidebar. Servers that use an external authorization server show a **Configure External OAuth** action there, and can later switch to platform-issued user sessions with **Convert to User Sessions**; see [User sessions](/docs/ai-control-plane/mcp-gateway/access/user-sessions).
+The Speakeasy AI Control Plane exposes a variety of different options for OAuth that can be integrated into built MCP servers. These are configured in the **Authentication** section of a built server's **Settings** tab, reached from [**MCP Gateway > MCP**](https://ai.speakeasy.com/@self/projects/default/mcp) in the project sidebar. New servers use platform-issued [user sessions](/docs/ai-control-plane/mcp-gateway/access/user-sessions). A server set up earlier with an external authorization server keeps working and shows that configuration read-only in the same section.
 The OpenAPI spec must include OAuth as a security option for its endpoints.
 
 ```yaml
 
@@ -23,6 +23,6 @@ Each environment card shows its name, description, and entry count, with actions
 
 Inside an environment, variables are listed with their keys and values. Sensitive entries are marked with a lock and a **Sensitive** badge; their values are masked, only ever return a redacted preview, and can't be copied out. A reveal toggle shows the masked preview inline.
 
-**Add Variable** creates an entry with a name, a value, and a switch that marks it secret. Each row's menu offers **Edit**, **Copy to Clipboard** (disabled for secrets), and **Delete**. The page menu adds **Fill for MCP Server**, which prefills placeholder entries for everything a selected server needs: security variables, server variables, function variables, and headers. Placeholders are created as secrets with empty values, so fill them in before the server is used. Attach the environment to a built server from the server's **Authentication** tab; see [Configuring environments for functions](/docs/ai-control-plane/mcp-gateway/building-servers/functions/configuring-environments) and [Add tools from an OpenAPI spec](/docs/ai-control-plane/mcp-gateway/building-servers/openapi#step-3-set-environment-variables). The same menu holds **Delete Environment**.
+**Add Variable** creates an entry with a name, a value, and a switch that marks it secret. Each row's menu offers **Edit**, **Copy to Clipboard** (disabled for secrets), and **Delete**. The page menu adds **Fill for MCP Server**, which prefills placeholder entries for everything a selected server needs: security variables, server variables, function variables, and headers. Placeholders are created as secrets with empty values, so fill them in before the server is used. Attach the environment to a built server from the **Environment Variables** section of the server's **Settings** tab; see [Configuring environments for functions](/docs/ai-control-plane/mcp-gateway/building-servers/functions/configuring-environments) and [Add tools from an OpenAPI spec](/docs/ai-control-plane/mcp-gateway/building-servers/openapi#step-3-set-environment-variables). The same menu holds **Delete Environment**.
 
 Environments bind to hosted MCP servers so that secrets stay centralized instead of living in individual client configurations. See [Authentication](/docs/ai-control-plane/mcp-gateway#authentication) in the MCP Gateway overview for where an environment is attached to a server.
@@ -173,7 +173,7 @@ Authentication answers two separate questions:
 - **Who is calling the server?** [User sessions](/docs/ai-control-plane/mcp-gateway/access/user-sessions) answer this. The platform acts as the authorization server and issues tokens to MCP clients.
 - **Which credential does the server use upstream?** [Upstream credentials](/docs/ai-control-plane/mcp-gateway/access/upstream-credentials) answer this, either per person through [remote identity providers](/docs/ai-control-plane/identity/remote-identity-providers) or with one shared credential for every caller. Secrets shared across servers live in [Environments](/docs/ai-control-plane/mcp-gateway/environments).
 
-Configure both on the **Authentication** tab of a built server, in the **Authentication** section of **Settings** on a tunneled server, or in the **Identity** and **Sessions** sections of **Settings** on a remote server. Changes take effect on new connections. See [Access, OAuth, and sessions](/docs/ai-control-plane/mcp-gateway/access) for how the two fit together.
+Configure both in the **Authentication** section of **Settings** on a built or tunneled server, or in the **Identity** and **Sessions** sections of **Settings** on a remote server. Changes take effect on new connections. See [Access, OAuth, and sessions](/docs/ai-control-plane/mcp-gateway/access) for how the two fit together.
 
 A built server can also authenticate against an authorization server outside the platform. [Secure with OAuth](/docs/ai-control-plane/mcp-gateway/building-servers/secure-with-oauth) covers the OAuth credential styles those servers accept, and [Build MCP with external OAuth](/docs/ai-control-plane/guides/oauth-external-server) covers pointing clients at a third-party authorization server.
 
 
@@ -25,7 +25,7 @@ The AI Control Plane is the OAuth authorization server for each MCP server, as d
 
 ## Prerequisites
 
-- A private MCP server in the AI Control Plane with user sessions enabled. The server's **Authentication** tab must show an identity provider rather than "No authentication configured".
+- A private MCP server in the AI Control Plane with user sessions enabled. The **Authentication** section of the server's **Settings** tab must show an identity provider rather than "No authentication configured".
 - A Foundry project, and permission to configure tools in it.
 - An [Azure API Center](https://learn.microsoft.com/en-us/azure/api-center/set-up-api-center). Developers find the catalog by the API Center name, so pick a descriptive one.
 - An Azure Key Vault that uses the Azure RBAC permission model, for storing the client secret.