When a popular budgeting app suddenly stopped letting users log in with their Google account in late 2021, thousands of people found themselves locked out, scrambling to create passwords they had never needed before. That disruption was not a bug. It was Google enforcing a security policy that researchers and internet standards bodies had been urging for years. Now, heading into mid-2026, the ripple effects of that decision are still reshaping how people think about the blue “Sign in with Google” button, and whether trusting it is worth the trade-offs.
The vulnerabilities that started the conversation
The technical case against blind trust in federated login traces back to a 2015 research paper hosted on arXiv, titled “Analysing the Security of Google’s implementation of OpenID Connect.” The researchers studied dozens of third-party websites and apps (known in the industry as “relying parties”) that accepted Google sign-in. What they found was not a flaw in Google’s own infrastructure. The problem was on the other side: outside developers were wiring up the login protocol incorrectly, leaving gaps that attackers could exploit to impersonate real users.
The specific weaknesses included incomplete verification of authentication tokens, mishandled redirect addresses, and sessions that were not properly tied to the person who had actually logged in. Chained together, these mistakes could let an attacker take over someone’s account on a third-party site without ever compromising their Google password. The paper, maintained through arXiv’s network of member institutions affiliated with Cornell University, has been cited extensively in security literature since its release.
Its core lesson is deceptively simple: a well-designed protocol does not guarantee a secure login experience if the app using it cuts corners during implementation.
The standards body warning that changed the rules
A separate line of pressure came from the Internet Engineering Task Force (IETF), the organization responsible for many of the technical standards that underpin the internet. In RFC 8252, published in 2017, the IETF laid out the security model for OAuth 2.0 in native mobile apps and issued a direct warning against “embedded user-agents.”
In plain terms, that means the small browser windows that many apps pop up inside themselves to show a Google login screen, rather than handing you off to your phone’s actual browser. The IETF’s concern was practical: those embedded windows strip away protections that a standalone browser provides. Users cannot reliably verify the URL they are visiting. Cookies and certificates are not isolated the way they would be in Chrome or Safari. And the app controlling the window can, in theory, observe everything typed into it, including passwords.
RFC 8252 carries real weight because browser makers and operating system vendors build their security models around IETF standards. It was not a suggestion. It was a formal best-practice document that signaled the industry’s direction.
Google’s enforcement and the fallout
Google acted on both the academic findings and the IETF guidance. In a post on the Google Developers Blog, the company announced it would block OAuth sign-in flows inside embedded webviews entirely. Warning messages began appearing on August 30, 2021. Full blocking took effect on September 30, 2021. Any app that still attempted to run Google sign-in inside an embedded browser received a specific error code, “disallowed_useragent,” and the login attempt was halted.
Google’s own account help page confirms the policy and instructs affected users to switch to a supported browser. The message is unambiguous: if an app is not opening Google’s login page in a full, trusted browser environment, Google will not let the sign-in proceed.
For users, the immediate effect was friction. Apps that had not updated their login flows simply broke. People who had never created a standalone password for those services were forced to set one up or abandon the app. Developer forums filled with complaints and workaround requests, and the experience left a lasting impression on users who had assumed federated login was a set-it-and-forget-it convenience.
What the evidence does not tell us
Despite the clear technical chain, from academic research to standards guidance to corporate enforcement, several important questions remain unanswered as of early 2026.
Google has not published data on how many users shifted away from federated login as a result of the 2021 changes. The trend is visible in developer communities and user forums, but no large-scale survey or official metric confirms its scope. It is genuinely unclear whether this represents a broad behavioral shift or a vocal minority reacting to specific breakages.
The 2015 arXiv paper that identified OpenID Connect implementation flaws has not been followed by a comparable empirical study measuring whether those vulnerability classes have decreased since Google’s enforcement. It is reasonable to assume that blocking embedded webviews closed some attack vectors, but “reasonable to assume” is not the same as “proven by data.”
There is also a real paradox in the user response. People who leave Google’s federated login and create separate passwords for every service may actually weaken their security if they reuse passwords or choose weak ones without a dedicated password manager. A single, well-protected Google account with two-factor authentication enabled can be more secure than a dozen standalone logins held together by the same recycled password. No published research has yet tracked whether the post-2021 fragmentation of login habits has helped or hurt users on balance.
The passkey factor
Any conversation about Google sign-in security in 2026 is incomplete without mentioning passkeys, the passwordless authentication technology that Google, Apple, and Microsoft have been rolling out aggressively since 2023. Passkeys use cryptographic key pairs stored on a user’s device, eliminating the need for passwords entirely and making phishing attacks far more difficult to execute.
Google has been promoting passkeys as the default sign-in method for Google Accounts and has encouraged third-party developers to adopt them through updated identity APIs. For users weighing whether to keep using “Sign in with Google” or switch to standalone credentials, passkey support on both the Google account and the third-party service is increasingly the most relevant variable. A service that supports passkeys sidesteps many of the implementation risks the 2015 researchers identified, because the authentication exchange no longer depends on tokens that can be mishandled by a careless developer.
That said, passkey adoption across the broader app ecosystem remains uneven. Many smaller services still rely on traditional OAuth flows, and users cannot assume that every app has caught up.
What to actually do about it
For anyone still using “Sign in with Google” across multiple services, a few concrete steps can reduce exposure based on what the technical evidence supports:
Check how the login opens. If a service displays Google’s sign-in page inside the app rather than handing you off to your device’s default browser, that is a red flag. The URL bar should be clearly visible and show a legitimate Google domain. If it does not, do not enter your credentials.
Enable two-factor authentication on your Google account. This remains one of the most effective defenses regardless of how third-party apps handle the login flow. Google supports hardware security keys, phone-based prompts, and authenticator apps.
Use a password manager for standalone logins. If you do create separate passwords for services that no longer support Google sign-in smoothly, a reputable password manager prevents the reuse and weak-password traps that make standalone credentials risky.
Look for passkey support. Where available, passkeys offer stronger protection than either federated login or traditional passwords. Check whether your most-used services have added passkey options, and enable them where you can.
A security upgrade with unfinished business
The technical community correctly identified serious weaknesses in how federated login was being embedded into apps, and Google’s enforcement of safer patterns aligned with formal industry standards. Those were the right calls. But the broader effects on everyday users, whether the shift away from “Sign in with Google” has made people safer or simply scattered their credentials across more surfaces, remain genuinely unstudied. Until that research catches up, the most honest advice is also the least satisfying: the answer depends on how carefully you manage whatever method you choose.
More from Morning Overview
*This article was researched with the help of AI, with human editors creating the final content.
