On this page
You shipped the OAuth flow. "Sign in with Google" works on your machine, works in staging, works for every user who lands on your marketing site from a Google search. Then your growth team starts posting the signup link in a TikTok bio and a Telegram channel, and your conversion-to-signup rate from those sources is a fraction of what every other channel does. The funnel logs show users hitting the auth screen and never coming back. It reads like a content problem. It isn't.
What's happening is that those users tapped your link from inside an in-app browser, and the OAuth redirect chain — the part that's supposed to hand off to the provider, authenticate against the user's existing session, and bounce back to your callback — quietly fell apart somewhere in the middle. The user never saw an error worth screenshotting. They just got stuck on a consent screen that asked them to log in to Google again, gave up, and swiped back to the feed.
the conversion problem OAuth-backed products face
An OAuth login is a redirect chain. Your app sends the user to the provider's /authorize endpoint, the provider checks whether the user already has a session, shows a consent screen (or skips it on returning grants), then redirects back to your redirect_uri with a code, which your backend exchanges for tokens. Every hop in that chain assumes the browser is a normal, cookie-bearing, multi-tab environment that can hold a session and follow a 302 back to your origin.
An in-app browser breaks that assumption in three places at once. First, the webview has its own isolated cookie jar — so the Google, Apple, or Microsoft session that proves "this user is already logged in" lives in Safari or Chrome and is simply not present, forcing a full re-login instead of a silent consent. Second, some providers actively refuse to render the consent screen inside an embedded webview at all (Google's disallowed_useragent is the well-known one) and return an error rather than authenticate. Third, the redirect back to your redirect_uri can land in a different browser context than the one that started the flow — the state parameter doesn't match, the PKCE code_verifier is gone, and the callback fails the exchange even when the user did everything right.
We named this problem the vanishing visitor and wrote the full mechanism explainer there. The short version for developers: the provider session and the originating flow state both live in the user's real browser. Your link opens inside the platform's webview, which has neither. The redirect chain either gets refused outright or completes into the wrong context, and a user who is genuinely logged into Google sees a login wall instead of a one-tap grant.
what this costs
OAuth conversion loss is hard to quote a public number for because it shows up as a soft drop, not a logged exception — your auth provider's dashboard reports "fewer successful sign-ins," not "in-app browser redirect failures." But the structural pattern is consistent, and it's worse than most destinations because the failure is hard-gated on the auth event itself.
For a product driving meaningful TikTok, Instagram, or Telegram traffic to a signup link, social-sourced sign-in completion typically lands somewhere in the range of half of what the same users would convert at if the flow had opened in their real browser. A consumer app pushing a launch through creator channels, a B2B tool with a Telegram community, a referral link shared in DMs — all of them lose social-sourced signups in the gap between "tapped the link" and "Google consent silently granted." The exact number depends on your provider mix and how aggressively the funnel leans on returning-session grants, but the math is meaningful at any volume because every lost signup was a high-intent user who chose to tap.
what linkboo does
linkboo replaces the URL you put in your TikTok, Instagram, Threads, Telegram, or anywhere-you-promote bio with a link-in-bio page (or a direct-route link — your choice) that has the in-app browser escape flow built into every outbound click. When a user taps your linkboo URL from any webview, linkboo detects it and immediately bounces the destination out to the user's real browser — Safari on iOS, Chrome on Android — where their provider session lives, before your auth flow ever starts.
The user doesn't see a friction prompt and doesn't need to know what "open in Safari" means. They tap, your signup page opens in the real browser, they hit "Sign in with Google," and the provider recognizes the existing session and grants in one tap. The redirect chain runs in a single, cookie-bearing, spec-compliant context from start to finish.
Concretely, for OAuth-backed products this means:
- The provider session is reachable — Google, Apple, Microsoft, and GitHub all see the user's existing login, so consent is silent instead of a full re-auth
- The consent screen renders — no
disallowed_useragentrefusal, because the flow isn't running inside an embedded webview stateand PKCE survive the round-trip — the flow starts and the callback lands in the same browser context, so thecode_verifiermatches and the token exchange completes- The fallback is graceful — if anything is off, the link still lands in the user's real browser (often already logged into the provider), not the cookieless webview
linkboo is also a full link-in-bio page — multiple links, themes, profile photo, the things you'd expect from a Linktree or Beacons alternative. The escape flow is the wedge.
the destinations where OAuth-backed products bleed the most
Deep writeup on the specific mechanism for the redirect-chain failure:
- OAuth redirect broken in in-app browser — the cookie-jar isolation, the
disallowed_useragentconsent refusal, and thestate/PKCE mismatch on callback, with the exact handoff the escape flow restores
If your product also offers passkey or magic-link sign-in, the same webview cookie-jar and context-switch failures apply to those flows. The full destination index is here.
why not Linktree, Beacons, or Carrd?
None of them have an in-app browser escape flow. They're link-in-bio pages. When a user taps a Linktree URL from TikTok and then taps your "Sign in with Google" button, the OAuth flow runs inside TikTok's webview exactly as it would from a raw URL — the provider session is still unreachable, the consent screen still may not render, the callback still lands in the wrong context. The structural sign-in loss is identical with or without their page in the middle.
If you're comparison-shopping the broader category, linkboo vs Linktree is the closest mainstream comparison.
pricing
Free up to a real volume of monthly clicks. No per-click pricing — which matters when you're routing a signup funnel and don't want a metered cost on top of every redirect. The escape flow works on the free tier; it converts as well as the paid tier on the thing that actually moves signups. See plans.
adjacent pages
- /for/magic-link-products — magic-link sign-in, same context-switch failure on the callback
- /for/passkey-products — passkey/WebAuthn flows that break in the webview
- /for/saas-founders — broader SaaS signup-funnel coverage
- /for/ios-product-teams — native and universal-link handoffs from social
- /for/telegram-channels — Telegram's in-app browser specifically
The user who tapped your link wanted to sign in. Don't let the webview be the reason your redirect chain dropped them.