CODEWITHSUNDEEP
facebook
EchtFettigerKeks
EchtFettigerKeks

Reputation: 1893

Common architecture for social registration with Facebook

Im just diving into the logic behind social login.

So far I geted the idea of creating a user authentification using the Facebook API.

The point which confusing me is the logical architecture of an web-app/-portal which uses social login for the user registration. When facebook returns to the site "logged into facebook" what should this website do now? Creating a new user entry in its own user database or something? And when the user is comming back and login in with FB again, should the website get the user-name and email from the facebook response and should compare the local user-database with some entries (before requesting the database for entry-data just based on the plaintext-user-name from FB)?

You see, Ive got no idea about the common architecture of such a login-solution. I dont even know the basic mechanisms of reading and storing users in a database in a proper way (getting user-informations just by a plain-text username or email as the key sounds very unsafe for me).

I know its a very abstract question.

Upvotes: 0

Views: 71

Answers (1)

Kit Sunde
Kit Sunde

Reputation: 37095

The only good answer is "it depends on your use case".

Logged into facebook

  • Some applications want to have their own user accounts. After logging in you can ask them to pick their username and password.
  • Some applications want complimentary information. After logging in you can ask the user for more information.
  • Some applications don't want or don't need any additional information. After the user has signed into Facebook, you show them the logged in view.
  • You don't authenticate the user with their Facebook email, you authenticate them with their UID. Emails change, uids do not.

What to store.

  • Typically you create a local user which holds a reference to the Facebook uid.
  • If you have a need for specific data like email and name, you would copy those into your local user account. The users access_token will expire after a while so you may need to keep a local reference.
  • If your app is only interacting with Facebook and doesn't really have state on it's own, you don't need to save anything locally.
  • If you need to keep requesting information about the user from Facebook after authenticating you would store their access_token, but it will expire if the user stops using your app.

On overwriting user edited data.

  • If the user edits fields on their local account you shouldn't overwrite that information because the user has intentionally overriden it. To make the data roll-back, would be confusing. If you are merely holding a local reference to their Facebook information, then by all means update it but don't present it in a manner where they can edit it.
  • If you want to allow the user to both have local data and need to reference their Facebook data you could keep both user.email and user.facebook.email fields.

Upvotes: 1

Related Questions