Live data from Hacker News

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

news.ycombinator.com

11–20 of 70 posts

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

#11
post #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.

According to Google Cloud, our App was created in 2018.

ChatGPT, Retool, Ramp, PostHog and HubSpot have the behaviour you've described.

I checked my browser history for `oauth/consent` and found the following examples with the loading behaviour:

HelpScout, Google Cloud, Termly.io

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

#12

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?

The server can't reliably detect that.

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

#13
It's madness to me that people (not OP specifically) will simultaneously say "you have to outsource login to a third party, storing passwords safely is too hard" and... also this.

The answer to "what can I do" is "stop depending on a third party service that's critical for your business and essentially trivial to replace".

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

#14
Not to excuse the non-debouncing behavior, but I wonder how much of those 15% are an actual loss, since it’s limited to users who are not interested enough to try a second time. I’m not denying there’s an actual loss, but it may be significantly less than the nominal 15%, and it would be interesting by how much.

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

#15
post #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, l…

Both interesting ideas! I'll pass along in my ongoing chat with Auth0. At first thought, the security implications don't seem problematic.

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

#16
post #5

Re whys: this can be even simpler. I sometimes catch myself rapidly click the mouse button a second time with my finger, right after the initial click. This is not intended and may be related to low resistance on the button itself.

Same, but for me it's because as I've gotten older, sometimes my finger gets unsteady enough to double tap something, mostly on touchpads rather than a mouse.

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

#17
post #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.

After watching network requests, I think it's based on the use of the Javascript login functionality vs. the redirect functionality.

If the "Login with Google" button opens in a new tab and the Google OAuth flow completes in the second tab, then the process will have the "loading" screen after clicking "continue" because "loading" indicates Google OAuth is communicating back to the original tab. If the "Login with Google" button opens in the same tab, clicking "continue" triggers a 302 redirect to your callback URL of which the loading speed is controlled by your website.

The immediate workaround is to switch to opening the Google OAuth login page in a new window.

edit: "Sign In with Google for Web" appears to be what provides the new tab for login functionality https://developers.google.com/identity/gsi/web/guides/overvi...

edit edit: that's not to say you're wrong, Google should definitely fix this but "Sign In with Google for Web" is not impacted in case anyone needs an immediate fix for their own apps, they can switch to "Sign In with Google for Web" (a difference user interface for OAuth).

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

#18
post #14

Not to excuse the non-debouncing behavior, but I wonder how much of those 15% are an actual loss, since it’s limited to users who are not interested enough to try a second time. I’m not denying there’s an actual loss, but it may be significantly less than the nominal 15%, and it would be interesting by how much.

Theory of mind error here. If it doesn’t work I may assume their system is down or doesn’t support my browser. Thus there would be no point in trying again, even if I was interested in the product. If it were to work on the second try it’d still be a sour taste - bugs are not a good first impression. At least personally I would have suspected the SaaS company as opposed to Google.

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

#19
post #11
post #4

Earlier quoted context omitted.

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.

According to Google Cloud, our App was created in 2018. ChatGPT, Retool, Ramp, PostHog and HubSpot have the behaviour you've described. I checked my browser history for `oauth/consent` and found the following examples with the loading behaviour: HelpScout, Google Cloud, Termly.io

Very interesting. I just tried in Termly.io as well, and I do see the loading indicator you mentioned, albeit not _immediately_ (if I throttle the network speed, there is a delay before it appears). I captured a HAR file and am inspecting it to see if it has anything revealing about why the loading screen appears in some cases but not others.

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

#20

It's madness to me that people (not OP specifically) will simultaneously say "you have to outsource login to a third party, storing passwords safely is too hard" and... also this. The answer to "what can I do" is "stop depending on a third party service that's critical for your business and essentially trivial to replace".

Login is never "trival" to replace.
Post reply on HN