13 ms·

Ask HN: Why does validating a user require 14000 files?

• aww_dang 5y ago
  Is it possible to use a generic oAuth library?
• ThePhysicist 5y ago
  Just use OAuth 2.0, which Google supports, no need to use the identity SDK.
• aliswe 5y ago
  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.
  • yashg 5y ago
    This is what Google suggests 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 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.
    • yashg 5y ago
      That does sound like a little too complicated to implement myself.
• 57844743385 5y ago
  “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.
• js4ever 5y ago
  I agree with you! I had the same issue with Google SDK and replaced that with 80 lines of code in my backend instead.
• jraph 5y ago
  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.
  • thom 5y ago
    Or at least, always use a custom domain if you’re going to do this. Although even then some places make it a faff to change to another workflow with the same address.
  • TeMPOraL 5y ago
    Seconding, and I'd like to refine the point further: > 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-youtube-emote-spam-markiplier/ 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.
    • MawKKe 5y ago
      I wanted to remove the profile picture on my account, but could not find such button anywhere in the account settings. So instead of removing, I replaced it with a blank white square. I thought I was clever. 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.
• maverwa 5y ago
  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-client https://packagist.org/packages/google/identity-toolkit-php-c... [2]: https://packagist.org/packages/google/auth https://packagist.org/packages/google/auth
  • yashg 5y ago
    I am using this https://github.com/googleapis/google-api-php-client https://github.com/googleapis/google-api-php-client Recommended by Google https://developers.google.com/identity/gsi/web/guides/verify-google-id-token https://developers.google.com/identity/gsi/web/guides/verify...
    • maverwa 5y ago
      Oh wow, yeah. Looks like the culprit here is google/apiclient-services which provides a fat client for EVERY google API [1] 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/tree/master/src https://github.com/googleapis/google-api-php-client-services...
      • yashg 5y ago
        I liked what jQuery UI does. It provides a web based configurator to choose what components you want to use and then you download a custom file with only those components. Really useful Avoid wasteful loading of code you are never going to use.
• asymptosis 5y ago
  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."
  • yashg 5y ago
    Of course I am not trying to validate just one user. But all I want to do is authenticate the token that Google has posted back on my auth endpoint and make sure 1) It has come from Google 2) Allows me to fetch a user's data (just email) so I know whose account I have to show. 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.
• stefanos82 5y ago
  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.
• 6510 5y ago
  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?
  • TeMPOraL 5y ago
    > but governments pretend a picture of a passport or ID card is sufficient(?!) 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.)
    • rambambram 5y ago
      > 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. 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.
• yashg 5y ago
  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.
  • tored 5y ago
    This is what I usually do too, it works well for projects where user management is minimal and the only way to use the product is visiting the web site. I mail the user a login link with a tamper free token, clicking the link will give the user a cookie.
• ramblerman 5y ago
  > 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!
  • pritambaral 5y ago
    > ... 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.
• zerof1l 5y ago
  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.
• herbst 5y ago
  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?
• 0x073 5y ago
  No one reads the readme anymore? https://github.com/googleapis/google-api-php-client#cleaning-up-unused-services 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:"
  • KronisLV 5y ago
    It feels like some sort of a tree shaking solution in most of our modern development stacks is long overdue. 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.
    • yummypaint 5y ago
      This sounds like it could be equivalent to the halting problem
      • herbstein 5y ago
        With a conservative analysis it's possible to make an underestimation on the names one can remove. This shouldn't be done on object files but at a level where program flow information is still preserved. A flow-independent analysis using a superset lattice over the callable names should do the trick for a first-order implementation that will look good enough compared to shipping 37mb for google authentication. Further you could make it flow-sensitive for a more accurate analysis with the caveat that the runtime will be significantly longer.
      • jitl 5y ago
        Control flow graphs are well-studied, critical parts of most compilers. The halting problem involves complexity of semantics in loops and jumps, but it’s possible to understand what loops may run just fine, without being able to decide exactly when a loop may exit. In many cases Clang and GCC compiler can easily understand loops, and even reduce them to constant time.
• AndrewDucker 5y ago
  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.
• sieve 5y ago
  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 https://github.com/sonic-pi-net/sonic-pi [2] https://quakewiki.org/wiki/.pak https://quakewiki.org/wiki/.pak [3] https://wiki.totalwar.com/w/Community_hints,_tips_and_tutorials#Introduction_to_Pack_Files https://wiki.totalwar.com/w/Community_hints,_tips_and_tutori... [4] https://sqlite.org/appfileformat.html https://sqlite.org/appfileformat.html
• sdevonoes 5y ago
  > 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.
  • yashg 5y ago
    I guess it boils down to personal preferences. I have come to detest passwords in general. Especially a new one for each website. (Because you don't know how the site is storing the passwords). I have created a Password Manager (HexaVault.com). If I am using a new service and it asks me to create an account, I go, "Oh man not one more password". Sure I can save it in my password manager which has around 500 passwords now I guess. 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.
• captn3m0 5y ago
  The ruby ones are split better, but still call in the grpc gem, which weighs at 409MB (Yup).
• o8r3oFTZPE 5y ago
  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
• nokya 5y ago
  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 :)