The trick is to be very forgiving: If a user tries to sign in using provider X, and we discover an email address conflict with an account that uses provider Y, we would simply ask users to confirm by clicking a button to sign in with provider Y. From that point forward, both provider X and provider Y can be used to sign into the account.
So many apps miss the importance of this and cut corners by only allowing an account to be associated with 1 sign-in provider, or forcing users to create passwords for these accounts, or differentiating between login and signup.
Maybe there’s something I’m not seeing, but it seems dangerous to rely on the identity provider’s email address to authenticate the user.
Some heuristics (such as email address matching) means you indicate to the user that perhaps they meant to try X? They sign in with X, and now you have authentications from X as well as Y for the user.
You use the authentication from X to authenticate, and you associate provider Y with the account as well. From this point forward, either X or Y can be used. You might also indicate these on a user profile page, possibly with other options - the user may decide they want to either revoke authentication from X or Y or add on authentication with Z.
You also have a similar behavior with multiple authenticators if you are implementing Web Authentication/FIDO, however these are "pure" authentication with no attributes so your heuristics for this sort of pre-login suggestion would be limited.
This is generally a reasonable thing to assume, and can be verified for whatever account providers you support.
I would consider this a best practice when iffering any “ sign in with...”
We offer only Facebook, Google, or Email. People see the email box and start typing in their email, they forget if they signed in with Facebook or Google previously.
I'm surprised it isn't the other way around. Of course, this wasn't an issue before we added email, but we got a bunch of requests from people who didn't want to sign-in with Facebook or Google.
We still have about 70% of our users who sign-in with social providers, so I'm not completely sure it was worth the headache.
Not familiar with latest sso implementation but what happen if base email used with a third party change. Does your token get revoked or does it persist? If so you can now detect that foo@aol.con is the same person than bar@gmail.con which is valuable information for dubious data broker.
However your solution... doesn't work. Apple requires apps that support social app to have sign in with apple. Google has similar requirements (because your app better be multi-platform in this day in age). Facebook is way popular. So that's three right there.
I don’t want to give my actual email out. I like the relay aspect. And it should make logging in and user management and single sign on and all that much easier no?
With Apple Sign In, I will consider trying it.
It reminds me of when I used to participate in a lot of gaming related forums and etc. The enthusiast crowd would pan a game as just terrible and unplayable ... and it would go on to sell lot hot cakes and just rake in the money.
(Also, everyone who uses Stripe for payment flow--not just processing, but with the Stripe widget--should take 10 minutes and enable Apple Pay. On the other hand, maybe please don't because then I'll be very broke and in debt with the ease of purchasing...)
A workaround is to use a domain you own and either point it at one of those services or set up a catch-all address with your e-mail provider. I do the latter. I have @subdomain.adomainiown.example configured at FastMail with * delivered to a folder in my main e-mail account. As a nice bonus, I can also send messages with alias@subdomain.adomainiown.example as the From address when needed.
Since it is a domain I own and no one else uses it, no services will likely stop me from using it. And since it's a subdomain, it's not easy to discover so spammers can't indiscriminately blast away at everypossibleaddress@adomainiown.example.
What's nice with SG is that the emails are sent to /dev/null once the count is over whereas with a catchall, you keep receiving everything sent to any address for ever.
That's true, and I wish Fastmail had a better way of managing rules remotely (with something like remote sieve or an API) so I could script a click-button-turf-address-forever. On the other hand, I don't mind still getting the follow-ups for some stuff. For example, Target has target@thatdomain.italkedabout.example for years to use for order confirmations.
https://developer.apple.com/news/?id=09122019b
https://developer.apple.com/app-store/review/guidelines/#sig...
I see it as oblivious executives trying to monopolize whatever they think they can monopolize.
The future is in yubikey-style authentication.
Just needing to have every hardware key on hand to register with each new service is so bad I thought I was misunderstanding the UI. I never used them again.
The hoops might be worth it for a critical service that holds your $millions. But hardware keys are never going to compete on the 99% of services that people use, from the trivia app on their phone to Uber.
It's orders of magnitude more secure to have a device that holds a key rather than depending on (a) website to support a particular authentication platform and (b) me having credentials for said platform.
I agree, not having direct unfettered access to the keys is a flaw in current implementations. Also I don't see the steps a person needs to go through or GUI intuitiveness as things that will prevent this kind of technology from becoming ubiquitous. I'm confident adoption will reach terminal velocity. Just not sure when it'll happen. I think it won't have a chance, though, until all the right standards are in place.
Along with a number of other enforcements.
Anybody think this is a bad idea for some reason?
I made the mistake once, had an account closed, got royally screwed. It wasn't Apple but it doesn't matter. I learned my lesson. Don't tie things together.
I don't follow that for everything but for anything important I do as well as anything involving money.
You could make the same argument if your password manager is compromised, but definitely worth being aware of
1. Use the same password for all logins because you don't know how to manage unique passwords for all your logins. Obviously this is about as unsecure as you can get.
2. Write your unique passwords down somewhere. This can be in a notebook, or a password manager (1password and the like). In this case, there is still a single point of failure (as you pointed out) if someone finds your book or compromises your password manager.
3. Use some sort of SSO service. Still a single point of failure (Apple, Google, Facebook).
I feel like using Apple SSO with 2-factor authentication is just as secure as any of these options.
Is there any "secure" system that doesn't have a single point of failure?
If you're looking for a point outside yourself, then memorising all your passwords would be an option.
But beyond that, I don't think your criticism is warranted. There's always a single point of failure - sure - but we can still consider gradations of how centralised that point is, and how likely it is to fail.
With a hosted password manager, you're at the mercy of their server code; specifically, at least for 1password, I think they have a 'dead man's switch' which lets you get at the encrypted content without the master password. This is more likely to fail than a password manager which stores all its content locally and really encrypts it (e.g. keepass). In this case, human error outside of yourself can't compromise you. But technical error can, which is why there are more steps that can meaningfully increase your level of security. Like running your password manager on a separate, air-gapped computer; or sandboxing everything you run a la qubes.
Are any of these especially likely to compromise you, as a user? No, but reducing centralisation and dependency still improve your chances, and are definitely worth considering if you are e.g. running a drug smuggling ring.
It keeps happening, and all it takes is one of the places you've used the password to lose it.
Generally "sign in with X" still provides an email recovery option.