By the way, I go out of my way to avoid signing into services using third parties for this reason. I don't use a Google account neither so I would be locked out of any service requiring one.

Your service will be highly dependent on Google if you only allow signing with Google and if they have a failure, your service will be unusable. Allowing other providers would highly improve this.

> The day Google decides to lock your account (..) you are locked out from your digital life.

It takes getting banned because of mischief, perceived mischief, or algorithmic error on one of their services to instantly, and usually permanently, lose access to all of their services, and any other third party service you logged into with Google.

In other words: make a "wrong" comment on YouTube, and you lose decade(s) of your e-mails. If you were running your small business off Google's Office Suite on your personal account, well, you can kiss your business goodbye.

(In case anyone doubts that happens, I recommend checking out https://9to5google.com/2019/11/09/google-account-bans-youtub... for a recent example.)

And, of course, this pattern of behavior is not limited to Google. Big cloud services all have problematic or nonexistent customer support experience - a consequence of scaling up without paying the associated costs. It's thus more important than ever to diversify one's digital footprint and minimize dependencies.

Instead, I got a strike on my account.

IIRC it takes three strikes and you're out. But if a strike is handed out due to such a silly thing, I wonder what the next silly thing is going to be?

Clearly I cannot rely on such a platform, considering I would likely NEVER get my account back. From that point onwards, I've tried to reduce my dependency on Google accounts as much as possible.

This. I make separate account everywhere. When site doesnt allow sign in with new account I dont bother.

I am no fan of the idea either, but I like the option to login on a single click.

If only we could get rid of dynamically called code and instead could evaluate which code paths the code actually can call, then we'd be able to throw out about 90% of the contents of libraries, since most of the time noone actually uses all of that functionality.

Doing that with separate scripts is another approach, but it feels like the problem should be solved at its root.

https://docs.microsoft.com/en-us/dotnet/core/deploying/trimm...

In many cases Clang and GCC compiler can easily understand loops, and even reduce them to constant time.

These managers dont replace the chain of trust, if you dont trust a dependecy and the developer behind dont install it.

"And it's impractical to audit them all." I dont use NPM but for composer.json: https://github.com/fabpot/local-php-security-checker

I agree, composer is not perfect, but before it was worse.

    {
        "require": {
            "google/apiclient": "^2.10"
        },
        "scripts": {
            "pre-autoload-dump": "Google\\Task\\Composer::cleanup"
        },
        "extra": {
            "google/apiclient-services": [
            ]
        }
    }

To paraphrase what @js4ever said, it would make sense to implement it yourself in your backend than depend on Google Sign In.

@jraph, I completely agree with you; it happened to me and stopped using Google, apart from an email I have for my mobile apps and that is rarely used.

It seems so simple to have a global standard for some government API with perhaps some [portable] card reader and perhaps some ISP logic. Nice developer tokens with permission levels that can be revoked?

Or is that [again] one more naive idea?

That's because forging the passport or ID card, or impersonating someone else with borrowed/stolen passport or ID card, are serious offenses that will land you in prison.

What's often forgotten when comparing digital and meatspace security is that "angry men with guns will come for you and put you in front of a judge" is a critical part of security systems in meatspace. The very possibility of it acts as a powerful deterrent for casual attacks. Governments can rely more on this than private companies, so at least in meatspace, you don't need to jump through as many authentication hoops as you need with banks.

(Digital is different, governments sometimes overdo the hoops there, because for any Internet-connected system the pool of would-be attackers consists mostly of people from outside the reach of law enforcement of the country that hosts the system.)

This sounds like governments and government 'officials' (ooh, you work for the government, now you are 'official') somehow automatically loose their jurisdiction somewhere between meatspace and cyberspace. They don't.

I mean, ask Kim Dotcom about angry men with guns. Don't ask him about the judges, I guess.

There was also a French government plan (there was an app in beta, i should take a look at it again) to validate user identity with a smartphone and conformant passport / ID card ( the recent ones with chips and NFC) - you use the app to read the biometric info from the passport / ID card, and then take a video of yourself which is then matched, thus confirming who you are.

As a comparison: looking at googles docs for "Google Identity Toolkit" (which is abandoned, thanks google!), the used google/identity-toolkit-php-client[1] composer package installs ~196 files with ~212k LoC PHP source, totaling at around 7MB. Still a lot for validating a token, but most of that is from the google/apiclient library, which seems to be a generic client for google APIs, and the google/identity-toolkit-php-client just adds 10 files and 729 lines of php code, which seems pretty reasonable.

[edit]: Looking at the more recent (and alive) google/auth[2] seems to add around 200 files with 12k LoC PHP, including the guzzlehttp client, some firebase client and some psr API stubs.

[1]: https://packagist.org/packages/google/identity-toolkit-php-c... [2]: https://packagist.org/packages/google/auth

Recommended by Google https://developers.google.com/identity/gsi/web/guides/verify...

In classic google monorepo culture, thats one package for all the things. A great example on how not to structure your SDK.

So yeah, you are right. Thats a lot of code if you only use like 0.25% of it.

[1]: https://github.com/googleapis/google-api-php-client-services...

A couple of years back I installed a copy of Sonic Pi[1] on my machine and was horrified to see that the distribution basically dumped tens of thousands of extremely tiny Ruby files on the hard disk. Ever tried copying hundreds of thousands of sub 1 KB files from one disk to another and noticed the file system crying under the load?

Game developers solved this problem decades ago.[2][3] I don't know why other developers continue to be so backward in their thinking when distributing their software. You don't have to do anything special. Just use SQLite as a VFS and end the insanity.[4]

[1] https://github.com/sonic-pi-net/sonic-pi

[2] https://quakewiki.org/wiki/.pak

[3] https://wiki.totalwar.com/w/Community_hints,_tips_and_tutori...

[4] https://sqlite.org/appfileformat.html

Ugh, please don't do that. The whole point of using this SDK is that people can trust it works, and if there are bugs you can just bump your dependency.

It's a fair point to make that libraries are bloated these days, but manually hacking down dependencies, or re-inventing the wheel are far worse practices!

Disagree. Allowing such bloat to permeate your codebase, and supporting such practices as this fat SDK, are far worse. Short-term gain vs long-term loss.

Besides the topic regarding "roll your own stuff" vs "use a huge library", I would ask a more business-oriented question: would your users be alright regarding signing in to your app using their Google accounts? What if they don't have one? Email address + password is usually a good approach when it comes to login: I can always use a fake email address if I don't trust your service, whereas if only "login via Google" is enabled, I'm just going to pass.

So if I see an option to login via some other service - Google/Facebook/Twitter/LinkedIn/Microsoft I prefer that.

What I have come to like is the password-less email only login on a few sites. They either mail you a link or a code to login. Which I think is the way forward. Nothing to remember as a user.

It's definitely the case that if you only want the one call out of the whole thing then you could get by with only a small chunk of that code, but writing the Client SDK so that each feature was entirely independent would be a lot more work for them.

So they make their lives easier, and you get to have an extra 37MB of code on your client.

I mail the user a login link with a tamper free token, clicking the link will give the user a cookie.

1. Developers who understand it's not efficient to reinvent the wheel, and also very often more secure.

2. Developers who wouldn't be able to do it without the framework.

3. Personal data stealing businesses.

Learn to recognize each :)

Aren't there any third party oauth libs for php?

To verify that the token is valid, ensure that the following criteria are satisfied:

The ID token is properly signed by Google. Use Google's public keys (available in JWK or PEM format) to verify the token's signature. These keys are regularly rotated; examine the Cache-Control header in the response to determine when you should retrieve them again.

The value of aud in the ID token is equal to one of your app's client IDs. This check is necessary to prevent ID tokens issued to a malicious app being used to access data about the same user on your app's backend server.

The value of iss in the ID token is equal to accounts.google.com or https://accounts.google.com.

The expiry time (exp) of the ID token has not passed.

If you want to restrict access to only members of your G Suite domain, verify that the ID token has an hd claim that matches your G Suite domain name.

Rather than writing your own code to perform these verification steps, we strongly recommend using a Google API client library for your platform, or a general-purpose JWT library. For development and debugging, you can call our tokeninfo validation endpoint.

The tone of your post implies it should be easy.

There’s lots of stuff to do when validating a user.

Sure it’s not going to use 14,000 files but it’ll use lots of libraries to get things done.

> I just want to validate one user.

This is important enough to you that you say it multiple times.

And yet, if I have just a single user, I can validate them easily: we agree on terms for exchanging auth info as a one-off, job done. I might agree to meet them in person and they show me their driver's license, or whatever. The details are irrelevant: we just use whatever we agree verifies this person.

I think that, just perhaps, you might have more than one user, and you're trying to scale this.

So, where are the details?

How much are you trying to scale, and what are the constraints around privacy and so forth.

You can't just say "I want a cheap perfect auth system with no constraints except for some hidden constraints which I'll explain later."

I can write my own authentication using a simple username, hashed password in php easily. I just don't want my user to remember yet one more password for yet another service on the web.