4 ms·
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 ser
by m0dest 7y ago
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.
- DerJacques 7y agoInteresting. 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.
- earenndil 7y agoIt'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 7y ago[deleted]
- Sleidom 7y agotest
- dwaite 7y agoYour 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.
- m0dest 7y agoExactly this.
- deleted 7y ago[deleted]