Federated sign-in works with Okta, and identity chaining gets consent, readiness, and an audit trail

Federated sign-in now works with identity providers that don't return an RFC 9207 iss parameter, including Okta's org authorization server, so Okta can sign people into the platform directly. A new Okta sign-in card in the dashboard walks through linking the agent and registering its public key, the consent screen now says when a service is already managed by your identity provider instead of showing it as disconnected, and every identity chaining change is now audited. More on this in Enterprise Managed Auth.

Features

Federated sign-in works with Okta — Every federated sign-in now uses a per-client callback URL, /mcp/idp_callback/{clientID}, which binds the authorization response to its issuer and no longer requires the identity provider to return an iss parameter. This makes federated sign-in possible with Okta's org authorization server, which doesn't return one. Remote session clients now report the callback URL to register with the identity provider. (#7341, @daviddanialy)
Set up Okta sign-in from the dashboard — A new Okta sign-in card registers the AI agent's linked app as the organization's sign-in client, shows the public key to paste into Okta and the redirect URI to register, and lists every sign-in issuer and whether it trusts Okta sign-in. The setup checklist walks through adding the agent's public key and activating the linked app in the order Okta requires. (#7343, @daviddanialy)
The consent screen and readiness checks understand identity chaining — A service that identity chaining already serves now shows "Managed by your identity provider" on the consent screen instead of looking disconnected, with a secondary option to connect manually. Identity chaining changes (enabling, scope updates, disabling) are now audited on the remote session client, and the Platform MCP's get_xaa_readiness tool reports each server's chaining bindings and the callback URL to register. (#7342, @daviddanialy)