Remote MCP servers get their upstream tokens from your identity provider, so users stop connecting each one by hand

Where a remote or tunneled MCP server is bound to your identity provider for enterprise-managed authorization, its upstream token now comes from the signed-in user's provider rather than from a connection the user has to establish server by server. The platform exchanges the user's retained ID token for an identity assertion, redeems it at the server's authorization server, and reuses the result until shortly before it expires. Readiness reflects what those exchanges actually observe, so a server that looks confirmed but refuses real traffic says so. Organization administrators with an Okta connection also get MCP servers suggested from their synced Okta applications, rolling out behind the okta-connections flag. More on connecting providers and registering their clients in Remote identity providers.

Features

Upstream tokens obtained from the signed-in user's identity provider — A remote or tunneled server with a ready identity chaining binding obtains its downstream access token by exchanging the user's retained ID token at the server's authorization server, so users are not asked to connect those servers one at a time. An interactive connection still takes precedence, and a server without a binding keeps its existing sign-in behavior. (#6902, @bflad)
Readiness reflects what exchanges observe — A confirmed server reads Verified once an exchange succeeds, returns to Not confirmed when the provider rejects the target, and reads Not working when scopes, the agent app's authentication, or the server's own authorization server refuses. A confirmation whose issuer URL does not match the server's authorization server now reads Not working until the mismatch is corrected, including existing confirmations. Result changes are recorded in the audit log, and confirming again clears an earlier result. (#6926, @daviddanialy)
MCP servers suggested from your synced Okta applications — Organization administrators with an Okta connection can list the MCP servers their synced Okta applications point to, then dismiss or restore each suggestion. A suggestion flags an app instance whose sign-on mode cannot support Cross App Access and marks a server the organization already runs. Rolling out behind the okta-connections flag. (#7003, @daviddanialy)
Add a suggested server straight from the Okta Applications tab — Suggested catalog servers appear on the Okta Applications tab with add, dismiss, and restore actions, so a server observed in the directory becomes a configured one without leaving the page. (#7038, @daviddanialy)
Identity providers get their own tab — The IDP and SSO page now opens on an Identity providers tab in place of Enterprise Managed Auth, matching the order of the work: a provider such as Okta is connected first, and enterprise-managed authorization is one use of that connection. The Okta page's Setup tab keeps only the connection itself. (#7032, @daviddanialy)
Pick client scopes from a multi-select — Choosing scopes for a manually configured identity provider client lists the scopes the server and the provider advertise, and a scope that is not listed can still be typed in and added. (#7068, @daviddanialy)