Home > database >  How to manage local authentication AND external authentication (OAuth)?
How to manage local authentication AND external authentication (OAuth)?

Time:07-14

Auth newbie here.

I am currently working on a project where I have to implement authentication. First I will be doing a basic local authentication as the target users might not have any kind of social network, so I will be using a database and user table for example: id | email | password | fname | lname | age | status

In the future, I would like to add some kind of social authentication using Facebook, Google etc...

Do I need to plan the user tables right from the beginning, as there will be some dependencies later on?

I read documentation around StackOverflow and I still don't understand if, for Social Auth, I need to store anything in my local database?

A - 1 user table for all users

From what I've seen, I should be able to retrieve some kind data such as email, name etc Would this flows be correct :

  • Log in with local auth -> Send JWT -> End
  • Log in with social network -> Get info from Social -> Add user to user table (if mail not present) -> Send JWT -> End

But then what happens for the required password field ?

B - 1 table for local auth, 1 table for social auth (or even 1 per social network)

Am I supposed to have a dedicated table for social auth and have some kind of join? I would have something like :

id | email | password | fname | lname | age | status

fb_id | email | fname | lname | age | status

google_id | email | fname | lname | age | status

id | fb_id | google_id (join on email)

But that seems wrong as I will have duplicated data and conflicting data (not the same name foe example)

The flow should be the same as A.

C - None of the above

Or am I supposed to store nothing ?

Thanks a lot !

CodePudding user response:

You don't need to store anything for the social auth. You're offloading the authentication to the social provider. They have the required table and info to authenticate the user.

The info you get about the user, either from something like a user info endpoint or in the ID token, is usually just used for a session, maybe stored in a cookie.

If you want to let them login locally the next time, you will need a way to retrieve passwords, even a hash if you know the algorithm, or you let them enter a password when you provision the account to your "local" database.

You might have some other reason for storing the user info, but it's not required.

  • Related