Live data from Hacker News

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

news.ycombinator.com

51–60 of 70 posts

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

#51
post #28

In your “What can I do” section, should add: “do not add google/apple/facebook(meta)/github sign on in the first place” Not only are we centralizing identity to entities known to shutdown accounts for vague reasons. It can introduce painful debugging issues, increased support costs, and loss of sales. Personally, dealt with an issue where a user signed up with “Sign in with Apple” but forgot whether they provided App…

As a developer I can sympathize having dealt with frustration implementing SSO but as a user (and I'm aware I may be in the minority on HN) I've bailed out of trying quite a few webapps that don't offer Sign in With Google or Sign in With Apple. There is a psychological effect where I dread the image of whatever half broken bespoke registration flow or inane password requirements someone came up with when I only see…

It isn’t for everyone, but I can’t imagine not using 1Password + Fastmail’s masked emails for registrations anymore.

All the privacy of throwaway email addresses with strong passwords. Services can store passwords in plaintext and use public blockchains as databases for all I care.

Figuring our which service leaked my email and blocking all messages from it is one click away.

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

#52

Just a PSA - I (and probably others) find the "Sign in with Google" pop-over extremely annoying. It annoys me both because it's over the top of stuff I might want to read, and also because it's Google threatening to tell this web site who I am even though I have no desire whatsoever to do that. Please hide it behind a login button or otherwise only show it when the visitor has actually demonstrated a desire to log in…

This uBlock Origin custom filter suppresses the popup. ||accounts.google.com/gsi/*$xhr,script,3p It's always the 1st one I install.

If you don't use uBlock Origin, you can also pihole or otherwise block the domain accounts.google.com. This is surprisingly non-destructive to active Google sessions, though you can't create new ones with it blocked.

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

#53
post #47

Just a PSA - I (and probably others) find the "Sign in with Google" pop-over extremely annoying. It annoys me both because it's over the top of stuff I might want to read, and also because it's Google threatening to tell this web site who I am even though I have no desire whatsoever to do that. Please hide it behind a login button or otherwise only show it when the visitor has actually demonstrated a desire to log in…

Staying logged out off Google at all times is slowly becoming basic web browsing hygiene. Picture a situation: - You interact with a bot in a mostly-idle, public chatroom (such as !commands on Twitch) - Bot pastes a url-shortened link that redirects you to a Google doc - Anyone who had that document already open can now link your Twitch identity to your Google identity (which may include real name+photo) Granted this…

How would they be able to link that? Document owners can't see non-domain users who viewed a particular document (and even for domain users, that can be disabled).

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

#54
post #28

In your “What can I do” section, should add: “do not add google/apple/facebook(meta)/github sign on in the first place” Not only are we centralizing identity to entities known to shutdown accounts for vague reasons. It can introduce painful debugging issues, increased support costs, and loss of sales. Personally, dealt with an issue where a user signed up with “Sign in with Apple” but forgot whether they provided App…

It's pragmatic if you're making (Android) apps, in which your payments are already tied into it, and you're already at Google's whims.

But websites shouldn't copy the ideal UI for Android and so on.

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

#55
I use authjs (aka next-auth) and recently documented that Google login requests additional access every time the user logs in[1].

I created an issue with a repro, although the maintainers moved it to discussions. It seems that the problem is with Google, but in that case I don't understand why the next-auth example works fine[2].

There are other users affected. If anyone knows how to solve this problem, I would appreciate it if you could say so.

https://github.com/nextauthjs/next-auth/discussions/11160 https://next-auth-example.vercel.app/

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

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

If handling a user identifier and a hashed password securely, and providing a means to reset said password is more than "trivial" relative to the rest of a business application, the whole scenario is moot anyway because it's going to be shut down before anyone who might attack it is even aware it existed: there isn't really a profitable market for hello-world and "my first todo" apps.

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

#57
post #38

Earlier quoted context omitted.

I agree with you, but I think the comment is about replacing Google, not replacing Auth0.

How so? Google is an IdP. It provides the user's identity. Auth0 is a middle layer that (in this case) transforms oauth responses into oauth responses. The thing you'd replace Google with would be something like oauth client auto-registration so people can use their own oauth server on their domain. Edit: Oh, I see what you/they mean. That's probably fair, but SSO is actually convenient for people, so it's fair to of…

> dealing with SSO is probably easier than handling passwords, reset flows, etc.

It's really not that difficult. Yes you need to be aware of risks, and be more careful with the data. But it's not exactly rocket science, and you're never going to end up in a scenario where your users can't login because the login flow is out of your hands, as per the topic of this thread.

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

#59
post #28

In your “What can I do” section, should add: “do not add google/apple/facebook(meta)/github sign on in the first place” Not only are we centralizing identity to entities known to shutdown accounts for vague reasons. It can introduce painful debugging issues, increased support costs, and loss of sales. Personally, dealt with an issue where a user signed up with “Sign in with Apple” but forgot whether they provided App…

As a developer I can sympathize having dealt with frustration implementing SSO but as a user (and I'm aware I may be in the minority on HN) I've bailed out of trying quite a few webapps that don't offer Sign in With Google or Sign in With Apple. There is a psychological effect where I dread the image of whatever half broken bespoke registration flow or inane password requirements someone came up with when I only see…

For me it is the exact other way around. If you don't have any other sign up system, I will bail immediately. I have a Google account, but it is "empty" and only used for settings and Android phones.

I don't want Google to know which services I am using and I had accounts shut down by big tech for non-specified reasons, probably because I didn't want to share my phone number.

Same issues could materialize that we have with Chrome now. I don't want to watch an ad when I log in to something.

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

#60

Earlier quoted context omitted.

How so? Google is an IdP. It provides the user's identity. Auth0 is a middle layer that (in this case) transforms oauth responses into oauth responses. The thing you'd replace Google with would be something like oauth client auto-registration so people can use their own oauth server on their domain. Edit: Oh, I see what you/they mean. That's probably fair, but SSO is actually convenient for people, so it's fair to of…

> dealing with SSO is probably easier than handling passwords, reset flows, etc. It's really not that difficult. Yes you need to be aware of risks, and be more careful with the data. But it's not exactly rocket science, and you're never going to end up in a scenario where your users can't login because the login flow is out of your hands, as per the topic of this thread.

> you're never going to end up in a scenario where your users can't login because the login flow is out of your hands

It's more likely that the person re-implementing the SSO flow is making a mistake and the login behaviour is getting messed up than the default Google/Apple SSO implementation that's deployed to billions of users and business critical for many companies that use that kind of SSO internally too.

Post reply on HN