Why does validating a user require 14000 files?

Slightly out of topic, but beware when using Google to authenticate everywhere. The day Google decides to lock your account and they don't care about you, you are locked out of your digital life.

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.

No one reads the readme anymore? https://github.com/googleapis/google-api-php-client#cleaning... "Cleaning up unused services There are over 200 Google API services. The chances are good that you will not want them all. In order to avoid shipping these dependencies with your code, you can run the Google\Task\Composer::cleanup task and specify the services you want to keep in composer.json:"

To joke about this absurd situation, I would say it would be a lot easier to go find the user yourself face-to-face and validate his or her data.

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.

Just use OAuth 2.0, which Google supports, no need to use the identity SDK.

Just some ramble... ...fin-tech goes out of their way to identify a user but governments pretend a picture of a passport or ID card is sufficient(?!) Talking with IT folk since the early days of the web I kept hearing high praise for anonymity which of course has its place... until it doesn't? The Orwellian "track people everywhere" scheme, at the time, did seem like a good excuse not to but today we get identified mostly for sinister purposes? (howmany files would facebook have in their project to track you?) As a developer most often I just want a user to be unique. That cant really be done without major effort. I prefer not to store any information about people but if I don't it gets easier to make a thousand accounts. Everything kinda works but if we are honest it doesn't? It works but the solution isn't to inform google when people log in where(!?) or to hand out your email address to everyone(!?) or to allow anyone to send registration mails from your server and get black listed(!?) Geo data? One can simply configure that. Facial recognition? One can have as many faces as one likes.

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?

What SDK are you using? That sound like its (able of) doing a lot more than just token validation.

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

This insanity is far more pervasive and has infected software distribution as well.

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

> I tried removing unnecessary services from composer.json. Still 14000+ files.

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!

> I thought of using Sign in with Google instead of creating my own authentication for a new project I am building.

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.

The Google Client SDK does an awful lot of stuff. In order to do them all in an efficient way it shares code.

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 decided not to use Google Sign In eventually. I will implement a password-less Email auth. Basically will mail the user an OTP to sign in every time.

That SDK is intended to include support for a bunch of different things, not just login. The actual login can be done in a couple of hundred LoC in PHP using cURL. I've done that for one of my projects. Search for OAuth 2.0 sample code. Once you understand it and get it working, other one-click logins like FB function in pretty much the same way. Adding support for them is trivial.

I agree with you! I had the same issue with Google SDK and replaced that with 80 lines of code in my backend instead.

Frameworks and SDKs serve three populations:

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 :)

To be fair. Oauth works completely without SDK as well, you just have to call the right URLs with the right parameters.

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

Why do you need users to sign in. Do they really want to sign in. What do they get out of it versus what do you get out of it

Using Sign in with Google just encourages use of Google. Is that really the best thing for users. Google is a privacy disaster

If you and your users truly both need authentication of each other why not let your users use x509 client certificates

You are probably already using x509 server certificates

The term "SDK" is synonymous with "unnecessary fluff". Its been that way since the 1990s

The ruby ones are split better, but still call in the grpc gem, which weighs at 409MB (Yup).

Is it possible to use a generic oAuth library?

oauth basically redirects the user to the provider, providing a callback url to your site, sending along a token that you should verify with the provider (google). thats basically it, there must be several generic providers for PHP for this but rolling your own is far from impossible and not that complicated.

“Validating a user” isn’t a simple thing.

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 don't think you're being clear on all the details. You say this:

> 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."