Re:Bypassing airport security via SQL injection
by shuntress on Thursday August 29, 2024 @09:34PM
(#41397023)
Trusting Google's OAuth not to vanish overnight is less stressful than managing your own username/password database.
And that's pretty much my point. 2FA? Password Resets? Account Activation? Updating Email Address? No thanks. I would rather not have to deal with any of that. I literally just need a unique identifier to associate with your data and preferences.
Re:Bypassing airport security via SQL injection
by jjav on Thursday August 29, 2024 @10:31PM
(#41397282)
> Trusting Google's OAuth not to vanish overnight
Sorry if I wasn't clear. It is not that google will remove the service overnight (although they are infamous for canceling things, but not that bad). The problem is google will lock out users randomly for no reason and no recourse.
If that user was using google login to access your service/tool, you lost that user and there is nothing you can do. You really don't want to gate the access to your product via an unreachable unresponsive third party like google.
Re:Bypassing airport security via SQL injection
by kijin on Thursday August 29, 2024 @10:20PM
(#41397230)
Many well-established web frameworks have plugins or components to handle user management out of the box, with sane defaults. Nobody should have to roll them by themselves with each hobby project. You're probably using a similar plugin to integrate with Google anyway.
Topic drift, but no tools should use google login. Doing that means handing over to google the authority to decide who can and can't use your tool. And we all know google support is nonexistent and unreachable, so once it fails it's forever.
If you market a tool, you'd really want to own the decision on who you can sell it to.
For a government organization though, I'd agree it makes sense to use a government-run login service. (government run, not outsourced so some for-profit third party!)