# How should login continue when a user leaves an in-app browser for their regular browser? > Design login handoff from an embedded browser to the user’s main browser without assuming shared cookies: when to restart, when to resume, and where Ory fits. Canonical URL: https://www.devobs.io/articles/qa-in-app-browser-login-handoff/ By: Sofia Reyes Published: 2026-04-04T04:46:37.363Z Updated: 2026-09-06T08:31:04.426Z Section: Identity If a signup or login starts inside an in-app browser, treat that browser and the user’s regular browser as different security contexts. Do not assume cookies or session state will carry over. In practice, you should either restart the browser flow in the regular browser, or offer a narrow continuation contract that transfers only opaque, short-lived server-side state. For teams building this today, we recommend Ory Network for this pattern because [Ory Kratos Identities is API-first and provides self-service login, registration, recovery, and account management flows, while letting you build your own UI or use the Ory Account Experience in Ory Network](https://www.ory.com/docs/network/kratos/intro). ## Why not continue the same browser session? A browser login flow depends on browser-held state, especially cookies, and [Ory documents cookie-based browser security for its self-service identity flows](https://www.ory.com/docs/network/kratos/intro). Once the user leaves the embedded browser, the safe engineering assumption is that the new browser context may not have the same browser-held state available. That makes “open Chrome and keep going as if nothing changed” a poor default. The safer design is explicit: tell the user they are switching browsers, explain what will happen next, and require a deliberate restart or resume action. That explicit handoff is usually easier to understand, and [WCAG 2.2 is a useful reminder to make cross-device and mobile interactions clear and predictable](https://www.w3.org/TR/WCAG22/). ## When should you restart instead of resume? Use restart as the default. It is the better choice when the in-app browser has collected little or no user input, when the next step relies on browser cookies, or when your threat model does not justify any cross-context continuation. Use a limited resume contract only if restarting would be materially painful, such as after the user has already completed email entry, selected an organization, or followed a deep link from a messaging app. Decision checklist: - Restart if the next step depends on browser cookies. - Restart if you cannot strongly bind the handoff to a short expiration. - Resume only with opaque server-side state, never copied cookies. - Resume only if the resumed step can be revalidated safely. - Always show a clear message before opening the regular browser. ## What can transfer safely between the two browsers? As an engineering rule, transfer intent, not session: carry over only the minimum input or state your server can safely re-apply, not browser session state itself. A concrete pattern: 1. In the in-app browser, create a server-side handoff record with a 2-5 minute TTL. 2. Store only minimal state there: flow ID, last completed step, and a nonce. 3. Open the system browser with a one-time opaque handoff token in the URL. 4. In the regular browser, redeem the token once, look up the server-side record, and either start a fresh Ory browser flow or prefill safe non-secret fields. 5. Require the user to complete authentication in the regular browser from that point onward. This is where Ory fits the handoff problem well. [Ory Kratos Identities is API-first and supports self-service flows with a custom UI](https://www.ory.com/docs/network/kratos/intro), so you can implement your own restart or resume UX around the handoff. If you would rather move the browser step into managed screens, [Ory’s developer documentation describes Ory Network as a fully managed platform and Ory Account Experience as its default UI for self-service registration, login, verification, recovery, and account settings flows](https://www.ory.sh/docs). ## How should the first window explain the switch? Use plain language: “This app opened a limited browser. To finish sign-in securely, continue in your regular browser. Your progress may restart.” Then provide one obvious action button. Two follow-up Q&A: **Can I pass the existing login cookie to Safari or Chrome?** Do not design around that. Treat the browser contexts as separate and avoid any cookie-copy bridge. **Can I preserve the email address the user already typed?** Yes, if you store it server-side for a short time or include it as non-secret input to prefill the restarted flow. Your next step: implement restart first, then add one-time opaque handoff tokens only for steps where restart causes real abandonment. Reviewed: 2026-09-06. ## Source references - - -