Live data from Hacker News

Tell HN: Google OAuth consent screen issue could be costing you signups

news.ycombinator.com

1–10 of 70 posts

Tell HN: Google OAuth consent screen issue could be costing you signups

#1
TL;DR: The "Sign in with Google" form doesn't debounce clicks on the "Continue" button, so it can trigger multiple redirect callbacks, in our case causing 15% of signups to fail. We've since reproduced the issue with several other companies' signup flows.

What's the issue?

A few months ago we (Flat.app) noticed that a meaningful fraction of signups-via-Google to our SaaS product were failing. I recently found out why, so I'm sharing this PSA for anyone facing a similar problem.

If your app supports "Sign in with Google", it's likely that new signups will fail if, on Google's OAuth consent screen, a user clicks "Continue" more than once. The error will probably be inscrutable to the user, depending on your setup, so they may just give up instead of trying again. In our case, we were losing around 15% of signups!

I encountered this issue while investigating failed signups for our product, but I've also reproduced it with other popular products including ChatGPT, Doordash, Expedia, and Snyk, so I assume it's widespread.

Some of these products use Auth0, as do we, but others don't, and they still generate an error of one kind or another.

For Auth0 specifically, the error is "You may have pressed the back button, refreshed during login, opened too many login dialogs, or there is some issue with cookies, since we couldn't find your session. Try logging in again from the application and if the problem persists please contact the administrator." The error tries to be helpful by listing potential causes, but it fails to mention the actual cause. That's because Auth0 wasn't aware of this failure mode, based on my correspondence with them.

Why does this happen?

After a user clicks "Continue" the first time, Google will respond with a 302 to the callback URL, passing along the authorization code and replaying the OAuth 2.0 state param. If the user clicks "Continue" again, Google will respond again with a 302 to the callback URL. The browser will abort the first pending request and issue a new request to the callback URL. Importantly, the state param is, as it should be, the same in both requests, and it typically incorporates a nonce (see https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#name-protecting-redirect-based-f). Since the nonce will already have been consumed by the first request, the second request will be rejected.

Why would a user click "Continue" twice?

Simple: poor UX in Google's consent screen. The "Continue" button provides almost no feedback that the click was registered, and the screen provides no feedback that any requests are pending. So, some users will naturally try again, especially if they're on a slow connection.

What can Google do?

Google could disable the "Continue" button with a loading indicator after the first click. That would ensure it's not possible to click it twice, and it would provide an improved UX by showing the user that something is happening.

Google's OAuth consent screen was redesigned at some point in the past few years. Allowing "Continue" to be clicked twice, with no visible feedback, may be an unintended regression.

What can I do?

Test this in your own application. Be sure to deauthorize your app before each test run so that you get the OAuth consent screen. You can do that in your Google account's Data & privacy section.

Also, check your logs for errors to see if you're losing signups. See if you can detect this scenario and, if so, provide a better experience to users, e.g., by acknowledging what caused the error and giving them a clearer path to continue.

Re: Tell HN: Google OAuth consent screen issue could be costing you signups

#2
We use Google OAuth to handle hundreds of registrations each day and haven't encountered this before. No errors, no customer reports. Following your instructions, I logged in to my own Google account, removed the connection to our app (via "Third-party apps & services") and then did the login again: after clicking "continue" the screen changes to "loading" instantly before redirecting after a few seconds. There's no ability to click "continue" twice. I then tried to sign up to your app following your instructions and I can reproduce the issue there: the screen doesn't change to "loading" view that I get for our app.

Can you share a copy of your OAuth consent screen settings? Maybe there's an option influencing this behaviour.

edit: we do not use Auth0, our Google OAuth connection is built in house.

edit edit: comparing the URLs, our flow redirects from `https://accounts.google.com/signin/oauth/id` to `https://accounts.google.com/signin/oauth/consent` after clicking "continue" whereas yours remains on `https://accounts.google.com/signin/oauth/id` before redirecting to your app so there's definitely something different in the behaviour.

Re: Tell HN: Google OAuth consent screen issue could be costing you signups

#3
Talk to me about this, "Since the nonce will already have been consumed by the first request, the second request will be rejected."

What if the nonce was still valid for the second response because your server detected that the connection was dropped for the first response?

Re: Tell HN: Google OAuth consent screen issue could be costing you signups

#4
post #2

We use Google OAuth to handle hundreds of registrations each day and haven't encountered this before. No errors, no customer reports. Following your instructions, I logged in to my own Google account, removed the connection to our app (via "Third-party apps & services") and then did the login again: after clicking "continue" the screen changes to "loading" instantly before redirecting after a few seconds. There's no…

Interesting! It's certainly possible there are additional factors at play beyond what I've found to this point.

Curiously, in all other apps I tested and mentioned, I don't see the screen changing to "loading" on them. Do you?

Meantime, I'm checking the OAuth consent screen settings to see if there's anything relevant.

Re: Tell HN: Google OAuth consent screen issue could be costing you signups

#6
This sounds like an issue that could be solved in your app. I hesitate to say it's an issue with your app, because I wouldn't have thought of it either, but you should be able to fix it without involving Google, and the fix is simple enough that Google can say it's your fault.

You are getting the same callback URL twice, and the second time the request is failing. Why not instead, if the user is already authorised, let them keep their authorisation and continue by redirecting the user to the same place they would go if it was a new authorisation? This solution works if you are using a session cookie.

If you need to set new cookies upon authorisation, that won't work because the browser won't receive the new cookie before the second request. Another possibility is to cache the whole request and response for a short time in case an identical request is received. Since the whole request is identical there will be no security issues from nonce reuse.

Alternatively, you could allow nonce reuse within a small time window. I'm not familiar with the web stack enough to evaluate the security implications of this.

Re: Tell HN: Google OAuth consent screen issue could be costing you signups

#7
I was about to leave a very witty "just be idempotent ;)" response but did not consider the nonce. I'd be surprised if Google is quick to change this, so I guess be stateful on the receiving server, persist that you handled a certain request already, and if you get a duplicate request, replay the response from the first one?

Re: Tell HN: Google OAuth consent screen issue could be costing you signups

#8
It's been a while since I've thought about this stuff, but can you put the state param into a cookie (possibly encrypted, but I don't think that's necessary)? Assuming you don't use something like auth0, you can clear the nonce cookie at the same time that you set the login cookie. If they come into your callback without a nonce cookie (or with a non-matching one), you can kick them back to your landing page (or last saved redirect page) without processing the login attempt. If they were already logged in because you already processed it, they stay logged in.

The attack the nonce is meant to prevent is tricking someone into logging into the wrong account, right? The attacker can't access or guess the user's cookie to put the right nonce into the URL, so I think that should be safe?

If auth0 were going to implement this in the middle for you, then there might be some subtleties to think about with the redirect on failure unless you always send the user to a landing page. More layers of redirects make this kind of thing hard to think through. What's the purpose of auth0 for what you're doing?

This might also not work if the authorization code is not re-usable (they're not supposed to be according to the spec) and your backend already used it. If it doesn't work, you could again kick the user back to a landing page, tell them the IdP had an error, and ask them to try again. Or I suppose if you're saving the login to a backend session, then it should just work and you can ignore the error.

Re: Tell HN: Google OAuth consent screen issue could be costing you signups

#9

Talk to me about this, "Since the nonce will already have been consumed by the first request, the second request will be rejected." What if the nonce was still valid for the second response because your server detected that the connection was dropped for the first response?

That's an interesting possible solution if you're in control of the server. If you're using a third-party vendor like Auth0 to handle the redirect callback, then of course you're beholden to their implementation.

In Auth0's case, it appears the nonce is consumed early in the handling of the callback. In my correspondence with them, I confirmed that they do see that the first request is aborted (in the form of a log), but they take no action as a consequence.

Re: Tell HN: Google OAuth consent screen issue could be costing you signups

#10
post #2

We use Google OAuth to handle hundreds of registrations each day and haven't encountered this before. No errors, no customer reports. Following your instructions, I logged in to my own Google account, removed the connection to our app (via "Third-party apps & services") and then did the login again: after clicking "continue" the screen changes to "loading" instantly before redirecting after a few seconds. There's no…

maybe if you throttle your network (e.g. "low end mobile") you can hit it?
Post reply on HN