What I don't understand is why OAuth is rarely talked about in a privacy context, however your OAuth provider knows all the sites you log into and when.
It's a privacy nightmare.
What I don't understand is why OAuth is rarely talked about in a privacy context, however your OAuth provider knows all the sites you log into and when.
It's a privacy nightmare.
For enterprise, the ability to shut out a user with one click is the overriding security feature.
I don’t know why anyone wants to use a federated identity to sign into things. Where did the messaging that it’s more secure come from, Google?
Why would I want the headache of securely storing credentials if I'm running a web app? I'd rather offload it onto Google. And yeah, it's probably more secure.
Why would I want the headache of having yet another login/password to remember, if (like most people) I haven't figured out password managers? I'd rather just use my Google identity, especially if I don't really care about this particular web app.
There's a way to do auth with just email as well. Any good service will have a "I forgot my password" flow. Instead of using passwords, why not use tokens you email them gated by a 2FA challenge?
I have both Google and Github Oauth flows added to this idea in code, and it works great for my purposes. Prior to coding agents, I wrote the code by hand and went over it a few times to ensure it worked and was safe (for the email token thing at least). I even wired up the Oauth stuff myself, without an agent. It's not hard.
With agents, it's super easy to audit this and also deploy services using them, so I'm not sure why any arguments here mention how hard it is nowadays. It's not hard, but it does expose what site a user is logging into. That's just a easy function for the user though, with known risks.
With Google email, if I use a site with email logins, Google STILL knows I used them. It's just in my email instead of a logfile that I authenticated to a site. I would note that as long as the token is alive, dependent on the provider's choices, Google doesn't know I'm going back again, and has no idea what I'm doing on the site. I'd trust Google over anyone else about this, even Github (as related to Oauth to avoid the nitpick that has been common here recently).
I would hardly call this a "security nightmare" (as someone else said, not you) as Google only knows someone is authenticating to a given URL which they've vetted (a little) during the setup process. Same for Github. If you don't like Oauth, or feel that then every site someone uses should provide an email login fallback.
This is only true if one doesn’t care about spam going to that identity
If you sign up on a site with your stock email, this is a risk as well. And for retrieving lost logins, you still have to have an email in there. Why does it matter if I use a burner Gmail account for this and don't they already provide spam protection?
Normal people just reuse a few variations of the same password across all of their accounts. Federated identity isn't bulletproof but it beats the heck out of reusing the same password.
Login tokens solves the re-use (but does put the onus on their email being secure).
Do you remember when people had to "remember" a password for every service they use? It is better to use a trusted third party. Sure these third parties are big corporations, but its safer for most people to have a login that just works, even at the cost of some privacy.
People trying to remember passwords is a pretty bad security situation.
I'm not an expert but so often folks on here throw criticisms without giving credit to some of the merits of solutions. Nothing is perfect, and progress can still be made. :)
A password manager can both take care of remembering unique passwords and allow privacy options
Hard to convince users that they need to be using a password manager if you run a SaaS. Also when things like LastPASS getting hacked are on the front page... imagine advising people to use that one! (I'm guilty of recommending LastPASS many years ago, before their first breach).
Good luck getting people to use one! Even when they do, the UX is a nightmare.
> its safer for most people to have a login that just works, even at the cost of some privacy.
Respectfully, I disagree in a time when all your data is being slurped up and resold constantly I hate any additional costs to my privacy.
> People trying to remember passwords is a pretty bad security situation.
But that's their problem, not mine. I'm an adult and I use a password manager.
It probably is more secure, to be honest. I trust Google to keep my account secure more than I trust some random website to store password hashes and verify securely.
Your OAuth provider can also vouch for anyone who pretends to be you, if they so desire. They can give access to anyone, including themselves.
Microsoft SSO does exactly this. They let you pretend to be someone else's email, making their SSO service pointless since you still need to do email verification anyways (at which point, just send a login token to sign them in, instead of using SSO).
Slight tangent.
The only way to preserve privacy while having a central and easy authentication mechanism I can think of is to use IndieAuth[0] which is built on top of OAuth 2.0.
Of course, you will need to be your own provider, using an IndieAuth provider service defeats the purpose, which is what I see most IndieWeb devs are doing.
You will need to own a (sub)domain though.
[0] https://indieweb.org/IndieAuth?redirected=IndieAuth
WebFinger + self-hosted Oauth provider is indeed nice. Unfortunately not widely available.
Take a look at Google's FedCM protocol as well
"It's a privacy nightmare."
Privacy nightmare in the real world, "tech" company wet dream in SillyCon Valley
There's two sides to every coin
I've done a bit of experimentation in this area. Check out https://lastlogin.net/.
You may also be interested in the FedCM protocol Google is working on.
Though given most people use gmail or outlook, the two main oauth providers (Google and Microsoft) will know anyway
True they'd know which sites you've signed up to, but not the login times, unless the service emails you every time you log in.
Every time you sign into an app, you get redirected to the auth provider to open a session there. So of course they know your login times.
I don't think you followed the thread. I began discussing the OAuth privacy nightmare, then the counter point was that the with email auth providers know anyway, but they don't know the login times necessarily, unlike with OAuth.
Three main providers
(Apple login is in nearly every iOS app and most websites)
It also makes authentication Not Your Problem. Getting someone else to handle password resets alone seems worth the squeeze.
Totally agree. Having to handle the password reset flow requires having reliable email delivery, which can be non-trivial. I usually start with supporting Google auth, and if I need more than that I'll add Microsoft and Apple too. Everyone already has at least one of those setup.
Corporations aren't interested in preserving privacy, quite the opposite. If you need OAuth for private use you'd have to roll out your own centralised directory.
I wouldn't call it a nightmare. It's a well documented design choice
Centralised identity is basically the government... and having some other entity behave the same way is not good.
there are some emerging mechanisms for offline verification that don't require AS in the OAuth WG. (I'm working on one of them)