Haven’t done anything with Apple sign in, but I worked with a lot of other providers before. If you have multiple options, users might forget what service they used. This becomes an even bigger problem if the paid for a service with a different provider and can’t find their purchase. If you do use something like this, only having one provider (only Apple) makes things less confusing.
I worked on the design and rollout of multiple sign in providers on a popular app. There are best practices that avoid these issues (users forgetting which service they used), but they are rarely implemented.
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.
Interesting. Wouldn’t that allow someone to sign up for service Y with an email address associated with an account in your system using service X, in order to get access to the account in your system?
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.
Your local account is associated with X, you attempt to sign in with Y, the Y authentication was successful but there is no local account associated with Y.
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. I'm not a big user of SSO in general, but on the few sites that I did use it, I'd forget whether I used SSO or not. Also, using SSO locks you into using that vendor. I've a couple of accounts that I'd like to change to normal uname/pwd but am locked into the SSO vendor (which I'm hoping to move away from)
On all sites/apps I’ve built offering SSO, we’ve gone out of our way to support linking of accounts and detecting existing accounts when claims like emails are found. Also allowing for merges after the fact.
I would consider this a best practice when iffering any “ sign in with...”
Wouldn’t the sign in mechanism (which validates e-mail) prevent this, in the sense than they won’t be able to get a third-party account to authenticate with for a particular e-mail without verifying ownership of that e-mail to the third-party provider?
You address this by only linking accounts once a user has successfully signed in with another provider. That way if their email exists from another provider, you're more certain that it's the same account
We have the same problem, it's probably our 3rd biggest support issue. "Where's my stuff??"
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.
It feels to me that Apple affords the benefit of Facebook, in that users do not anticipate asking "where's my stuff". But the added benefit is the perceived security and reliability of Apple.
It's fairly straightforward to let them work interchangeably ... We run FB, Google and passwordless email for login. It doesn't matter which you use, email address is the uid between them. Obvs where a common email address hasn't been used (or isn't available ... does apple login use their proxy emails?) this becomes an issue.
Which is in retrospect is a good move as more than one people here casually explained that they aggregated identities from different third party at login for convenience... I'm not really sure this kind of behavior is RGPD compliant.
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.
Doesn't most services just create an account like normal when you sign in with eg. Google, if the email is verified? Then you can just use the forgot password and use your mail to log in without Google even if it was created with Google. At least that is my experience.
I've definitely been stuck in a loop where it said that I signed up with Google and must use Google to sign in when I tried to use my email to reset my password.
Yes, that is a problem. If your app/site supports multiple login options you may have users who "lose" their account (I'm one of them).
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.
If it was my app, I wouldn't use any. My recommendation only shows how out of touch I am with social providers since I haven't touched them in probably 4 years. Thanks for the heads up with the Apple and Google requirements.
Second that. We analyse where our users are coming from across all channels and added only that. This made it really easy for the users to both remember what they used and also to sign up/sign in almost instantly.
On one consumer iOS app with email and apple sign in as the two available options, 34% opt for apple, 66% for email. No meaningful change in conversion rate, but this generally isn't an issue 90%+. The prior arrangement wasn't just email, though, it was email or phone sign up, so take what you will.
I’m not a dev but a consumer in this question and I’d just say a service or site that has Sign In with Apple and Apple Pay available on the web is and instant use on my end. I will continue to vote with my paltry wallet for these technologies to take off even more, especially Sign In with Apple.
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?
I don’t want to sound dismissive but the fact that a very tech-savvy HN user likes Sign In with Apple isn’t all that indicative of anything broader. I think that’s why the OP wanted to know what things look like on the backend.
Yeah I suspect that could be a very narrow crowd / experience being expressed.
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.
I'm the same way. I needed to order some aquarium supplies and didn't feel like doing the copy-paste-credit-card-number dance so I clicked around the list of distributors listed on Seachem's web site until I found one who accepted Apple Pay.
(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...)
The issue I ran into in the past with sites like spamgourmet is once they get moderately known, other sites start blocking the use of their addresses (that is, Zorflab.whatever will refuse to let users put in a @spamgourmet.com address).
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.
Yes, this happens. Although I've been using SG for something like 10 years now and it's rare when a website blocks @SG (and the dozen other synonym domains) addresses.
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.
> 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.
You can also set a SG address to always forward emails coming from a particular email. So you could set it so that orders@target.com is always forwarded and doesn’t change the count and you’ll always get these but not the newsletter.
Originally Apple set a very aggressive due date for this feature and the dev's fought back. So the due date was pushed back to April 2020. Moving forward you should start to see it appear on almost any app that already has social auth.
Except of course if you are Google or Facebook themselves since it is considered 1P sign in. Many people don’t see it because they are mostly logging into these big services. Smaller services are just dropping 3P in favor of direct sign up. With auto fill and suggested password the friction is low. I have seen some social apps that don’t want to give up on Facebook login add Apple buttons (Bumble). These are my observations.
I haven’t seen it until about 5 minutes ago— the ZDF (one of the German national broadcast channels) uses it for their on demand app. Otherwise I frequently use Apple Pay with Lieferando (a European delievery Service). Have to say it’s pretty seamless and it saves me 3 taps compared to paying with PayPal.
Yubikey-style is dead in the water since you can't back them up or exfiltrate the key. It will never appeal to more than a handful of users willing to jump through those hoops.
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.
I think we will see most client devices natively implement something like WebAuthn with their onboard TPMs. Enrolling new devices for a service would then by a matter of approving the attempt from an already-enrolled device, iCloud style.
yubikey-style. I think it's about the concept, not a specific implementation.
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.
I'm looking at adding this into a new app I'm developing, and assumed I'd do a default apple login on IOS and google login on Android (with the option to go see more login options on other devices)
I’m about to embark on a new iOS built with SwiftUI. What backend would you recommend for authentication (server side) when using Sign In with Apple? Do you all use Firebase?
I will never use the same service to sign into multiple things. It's a single point of failure. If Apple ever decides to close your account you're S.O.L.
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.
Just to expound on what you're saying, won't there always be a single point of failure? For example, for the majority of people there are only a few options.
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?
You. You are the single point of failure; if you are compromised, then all your accounts can be accessed by the compromisor.
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.
Most people are already vulnerable to this because they use the same password everywhere. The fewer service providers there are holding a copy, the lower the risk of compromise.
This is not how it works. We don't hold any copies of users' passwords these days, there are hashes for that. Certainly, some old, or poor quality in-house software still do it, but then it won't offer you integration with whatever SSO service anyway. And single point of failure is very real, if you trying to operate world-wide: sign-in with X may suddenly become illegal, or inaccessible outside of the USA.
