Apple Sign in to be mandatory by June 30th for certainuse cases (source: Apple WWDC update email from a few days back).
Along with a number of other enforcements.
Ask HN: Mobile devs who added Apple Sign In, what conversion changes?
61–70 of 73 posts
Re: Ask HN: Mobile devs who added Apple Sign In, what conversion changes?
#62Haven’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…
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.
Re: Ask HN: Mobile devs who added Apple Sign In, what conversion changes?
#63Earlier quoted context omitted.
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…
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.
It's assumed that, if you're signed up for a service with an email address, you control that email address.
This is generally a reasonable thing to assume, and can be verified for whatever account providers you support.
Re: Ask HN: Mobile devs who added Apple Sign In, what conversion changes?
#64Earlier quoted context omitted.
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.
The user is given the choice to use their email, or a proxy email, in the modal that Apple provides on the system side.
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.
Re: Ask HN: Mobile devs who added Apple Sign In, what conversion changes?
#65Earlier quoted context omitted.
Similarly if your Apple (or other SSO) login is compromised the blast area is much bigger as all linked sites are now compromised You could make the same argument if your password manager is compromised, but definitely worth being aware of
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…
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.
Re: Ask HN: Mobile devs who added Apple Sign In, what conversion changes?
#66[deleted]
Re: Ask HN: Mobile devs who added Apple Sign In, what conversion changes?
#67Haven’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…
[deleted]
Re: Ask HN: Mobile devs who added Apple Sign In, what conversion changes?
#68Earlier quoted context omitted.
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.
It's assumed that, if you're signed up for a service with an email address, you control that email address. This is generally a reasonable thing to assume, and can be verified for whatever account providers you support.
[deleted]
Re: Ask HN: Mobile devs who added Apple Sign In, what conversion changes?
#69Earlier quoted context omitted.
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.
It's assumed that, if you're signed up for a service with an email address, you control that email address. This is generally a reasonable thing to assume, and can be verified for whatever account providers you support.
test
Re: Ask HN: Mobile devs who added Apple Sign In, what conversion changes?
#70Earlier quoted context omitted.
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…
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.