The Redirected Sign-In: Internet Identity’s ICRC-167 Transport Makes MCP Auth Fit More Browsers

Internet Identity’s latest MCP milestone is less about adding another AI feature than about changing where authentication happens. In the July 31, 2026 release, the service added ICRC-167 URL transport as a signer transport and enabled a more seamless app sign-in journey. The release also says that Internet Identity was prepared for MCP general availability.

URL transport uses top-level browser navigation. Instead of opening a signer in a popup and exchanging messages through postMessage, an application sends the request in the URL fragment, the signer processes it, and the browser returns to the relying party’s callback URL with the response. The official @icp-sdk/signer package describes this flow as useful when popups are unavailable, including full-page redirect journeys.

That detail matters for MCP clients. AI tools increasingly run in environments where popup behavior is restricted, inconsistent, or unavailable. A redirect-based flow gives the client a conventional browser hand-off while preserving the signer model: the application still requests an authorization or signing operation, and Internet Identity still mediates the user’s approval.

The release adds two important safety signals alongside the transport. First, the interface shows which identity an MCP connection will act as. Second, the release includes a migration that enables AI access for anchors using the official connector. These changes make the authorization context more visible and reduce the risk that a user approves an action without understanding which identity is being delegated.

Developers should treat the callback URL as a security boundary, not as a convenience parameter. The SDK documentation says the callback must be an absolute URL on an origin controlled by the relying party and must be declared in that origin’s /.well-known/ii-auth-callbacks allow-list. Each major flow—connect, sign, or attribute request—should have its own route and callback URL so that a fresh request and the signer’s return are handled deterministically.

The practical takeaway is that ICP authentication is becoming more transport-flexible at the browser edge. MCP integrations can support popup and redirect environments without inventing a separate credential system, but the redirect path does not remove the need for origin control, callback validation, user-consent clarity, or careful identity scoping.

A factual caveat remains: the July 31 release and the SDK package document the transport and Internet Identity changes, but they do not prove that every third-party relying party has adopted URL transport in production. Adoption remains application-specific.