When “Login with Google” Does Not Work, and There Is Nothing You Can Do About It

On the authentication page of my website there are two OAuth options: GitHub and Google. GitHub login has worked since launch. Google login has never worked.

This is visible to users. The button is present. Clicking it fails. It looks like a bug.

The Google OAuth integration has been production-ready since day one. It requests only basic profile information: email address and name. No sensitive scopes. No restricted access. No API usage beyond authentication.

Despite this, the application has been under Google review since November 23. Update as of January 04, it is fixed.

How this happened

During setup, I configured a standard OAuth client and uploaded a logo when prompted. At no point did I request elevated permissions or sensitive scopes. Nevertheless, the app was placed into a mandatory verification queue that I did not explicitly opt into and cannot exit.

Since then, I receive periodic automated emails stating that the app is “still under review.” No changes are requested. No issues are identified. No timeline is provided. There is nothing actionable to respond to.

The contrast matters

The GitHub OAuth integration was approved immediately. Same implementation. Same scope level. Same production environment.

That contrast rules out misconfiguration and points to process. One provider treats minimal OAuth as a default case. The other routes it into an opaque review pipeline with no clear criteria or timeline.

The real failure

The problem is not that review exists. The problem is that it removes all agency from the developer while exposing a broken experience to users.

There is no warning that certain setup steps will trigger review. There is no fast path for non-sensitive use cases. There is no “pending review” mode that prevents a public login button from failing. The result is a site that looks unfinished even though the work is complete.

A better system is possible

This does not require weaker security. It requires better defaults:

• Explicit opt-in to verification rather than silent escalation
• A fast path for minimal scopes like email and profile
• Visible status and expected timelines
• A safe disabled state for authentication during review

These changes would not reduce safety. They would reduce unnecessary friction for small teams and independent developers.

Why this is worth documenting

Authentication is foundational. When it fails publicly and indefinitely, it damages credibility in ways the developer cannot correct.

This is not a complaint about OAuth. It is a record of how a simple, correct implementation can still be blocked by a process that offers no feedback and no path forward. Documenting that gap is the only way it becomes visible.