2

It is popular today for frameworks and social sites to enable multiple authorization options when creating websites. For example, allowing a user to login with GitHub, Twitter, Facebook, etc. In addition, identity verification using mobile verification codes is also becoming more common.

Enabling these features seems to bring an added security risk, if not handled appropriately. For example, when changing a password - users are asked to either provide their past password or reset the password via email - even if the user is currently logged in or authenticated. However, there are cases where a similar manner of identity verification is not enforced prior to adding connected accounts/logins.

What are recommended strategies or best practices for adding or modifying additional authorization/login options while following proper precautions?

  • 1
    To my mind, the biggest risk of logging in to, say, SE with something like Facebook is that Facebook (aka the Evil Empire) then knows I logged in to SE. So, my idea of best practice is *don't do it.* – Bob Brown Dec 17 '14 at 18:40
  • I should mention that I'm looking for how to properly handle these scenarios from an application design perspective, not a user's perspective. – Craig Smitham Dec 17 '14 at 18:44
  • @BobBrown, user tends to not know that FB knows :) – elsadek Aug 15 '15 at 22:27

1 Answers1

2

Bear in mind that when you enable third-party account authentication in your application it is because you're delegating Identification AND Authentication to that third-party, that you choose to trust.

For instance, if the user chooses to login to your application using a third party account, your application doesn't have to be aware when the user changes his password. Rather it's up to your application to keep the user loged in permanently or ask him for login again (using the third party account) each time he get access.

elsadek
  • 1,782
  • 2
  • 17
  • 53