facebook · messenger · oauth
Facebook in-app browser OAuth
Inside Facebook and Messenger, two different things break your sign-in, and almost every answer online treats them as one.
The first is policy: Google refuses OAuth in any embedded browser. The second is mechanical: a popup cannot open in a single-tab browser.
Fixing the second does not fix the first. That is why the popular fix appears to work in testing and still loses visitors.
failure one, policy
error=disallowed_useragent
Google will not run sign-in in an embedded browser. Nothing in your page changes this.
failure two, mechanical
signInWithPopup, no error
The popup cannot open, the SDK quietly falls back to a redirect, and the redirect never completes.
the popup failure
Facebook’s in-app browser shows one page at a time. A sign-in flow that expects to open a second window has nowhere to open it.
The Firebase JavaScript SDK handles that by falling back to a redirect, silently. In this browser the redirect does not come back.
the in-app browser falls back to a redirect when the SDK tries to open a popup… I have filed a bug internally (b/182168083) to make signInWithPopup() fail fast with a relevant error message if it’s called within the context of a Facebook webview.
That is worth reading twice. The SDK maintainers agreed the call should error and does not. Your monitoring sees nothing.
The mitigation for this half is to detect the embedded browser and call the redirect flow directly instead of the popup flow.
I believe there are ways to detect whether your app is running in one of these webviews: a possible mitigation here is to use signInWithRedirect() if you detect you’re in a Facebook webview.
Do that. It removes a silent failure. It does not make Google sign in anybody, which is the other half.
the policy failure
Google has blocked OAuth in embedded browsers since 30 September 2021. The rule is written against the browser, not against your intent.
A developer must not direct a Google OAuth 2.0 authorization request to an embedded user-agent under the developer’s control.
The stated reason is that whoever embeds the browser can read what passes through it, and that is a live concern here.
In August 2022 Felix Krause documented that Facebook’s and Instagram’s in-app browsers inject script into every third-party page they open.
So a redirect from inside Facebook’s browser reaches Google, and Google refuses it for the same reason it refuses a popup.
One honest gap: we could not find a verbatim, Facebook-specific error string published for Facebook Login itself failing in a webview. Google’s refusal is documented. The Facebook Login equivalent is not, so we do not claim it.
which failure you are looking at
- a visible 403 page naming disallowed_useragentthe policy failure, from Google
- a button that does nothing and logs nothingthe popup failure, falling back to a redirect
- a white screen after the password is submittedthe policy failure, rendered blank by the embedded browser
what does not work
Ranked by how often they are recommended. Each fails, and the reason differs each time.
switching to signInWithRedirect and stopping there
Half a fix. It removes the silent popup failure, and Google answers the redirect with disallowed_useragent, so nobody signs in.
spoofing the user-agent string
Google stopped reading only that string. Commenters on the top-voted answers recommending it report the refusal unchanged.
window.open with a chrome: or custom scheme
Tried and reported as not working from inside the embedded browser. Chrome's documentation says an untapped script cannot launch another app.
waiting for the SDK to throw so you can catch it
The internal bug to make the popup call fail fast was filed in 2021. Do not build on an error message that may not arrive.
telling visitors to open the page in Safari
Facebook and Messenger do ship that menu. It is three taps deep in someone else's app, and most people will not take them.
what works
Two fixes are real, and they are not alternatives. Which one applies depends on who embedded the browser.
inside your own app's webview
use the platform's real browser component
Google names both replacements: Android Custom Tabs instead of WebView, and SFSafariViewController instead of WKWebView.
Both satisfy the policy, because both are the phone’s own browser.
Useless for taps from Facebook, whose browser you do not control.
for taps arriving from facebook or messenger
escape at the link, before your page loads
The tap on your link is a real user gesture, and it is the only one you get. A server-resolved link can spend it on handing the destination to Chrome or Safari.
Then both failures disappear at once: a popup can open, and Google recognises the browser.
Detection alone cannot do this. The escape has to happen before your page renders.
Being plain about our position: the second fix is what shorts is. This page is accurate whether or not you use it.
does your own signup page have this problem
Paste your signup or login page. We read it once and name every sign-in button that cannot complete inside an in-app browser. No account.
we read the page once and tell you what breaks. free, no account, nothing stored about you.
We read the signup pages of well-known products the same way, and most offer a sign-in that cannot complete there. That is the report.
A shorts link does the escape and counts every tap by source app. free keeps 5 links and 30 days of taps. shorts Lifetime is $49 once, with nothing recurring.
sources
Every claim above comes from one of these.
- firebase-js-sdk issue 4421both engineer quotes, the internal bug b/182168083, and the redirect mitigation
- Google, OAuth 2.0 policies: use secure browsersthe policy sentence quoted above
- Google, security changes to the OAuth endpoint in embedded webviewsthe 30 September 2021 date, the reasoning, and the Custom Tabs and SFSafariViewController guidance
- Felix Krause: announcing InAppBrowser.comwhat Facebook's and Instagram's in-app browsers inject into third-party pages
- RFC 8252, section 8.12: embedded user-agentsthe same rule, as a standard rather than a policy
- how to avoid 403 disallowed_useragent from a third-party appthe workarounds people try, and why the accepted answer gives up
- Chrome, Android intentsthe user-gesture requirement for launching another browser
written 26 Aug 2026 · corrections to shorts@nanocorp.app
short answers
- Why does OAuth fail inside Facebook's in-app browser?
- Two reasons at once. Google refuses sign-in in any embedded browser, and a popup-based flow cannot open a second tab in one.
- Is the popup problem the same as the 403 error?
- No. They are separate failures. A popup that cannot open is mechanical; disallowed_useragent is Google enforcing a policy.
- Does signInWithRedirect fix it?
- It fixes the popup half. Google still refuses the redirect, so Google sign-in remains broken inside the embedded browser.
- Why does the SDK not tell me what went wrong?
- A Firebase engineer confirmed the popup call silently falls back to a redirect, and filed an internal bug to make it fail with a real error instead.
- Does this affect Messenger too?
- Yes. Messenger opens links in the same kind of embedded browser, and the same two failures apply.
- What is the actual fix?
- Get the visitor into Chrome or Safari at the moment they tap your link, before your page and its sign-in buttons render.
the other answers
Same mechanism, different app. Each page is sourced separately.
- Error 403: disallowed_useragentGoogle blocks OAuth in every embedded browser, so sign-in fails inside Instagram and TikTok. What the error means, what does not fix it, and what does.
- Instagram google login not workingSign in with Google fails inside Instagram's in-app browser, usually as a white screen with no error. Why it happens, and the two ways out.
- TikTok browser sign inTikTok opens every link in its own browser, and Google refuses to sign anyone in there. TikTok is also the one app with no open-in-browser button.
All of them are listed on the answers page.