It is an architectural question rather than a technical one. Our web and mobile application are totally dependant upon social authentication and we are using social authentication providers such as Google, Facebook, and many others.
On successful user login, providers like Google and Facebook return the user's data with email and a unique id. We are storing that data in the database something like this.
+----+--------------------------------------------------------------+---------------+----------+
| id | socialId | email | provider |
+----+--------------------------------------------------------------+---------------+----------+
| 1 | $2a$12$Qx.FVkgYkXqJGF4PyJ1kb.JlSDe9bV6TJFodpTx2eBsYxvqn6Gywa | a@example.com | Facebook |
+----+--------------------------------------------------------------+---------------+----------+
| 2 | $2a$12$N2fCTRxymPlcaID5oP617OJTXkrvKAHZ/taFJ.lePZddfW3E6U.Fe | b@example.com | Google |
+----+--------------------------------------------------------------+---------------+----------+
All database fields are required and not nullable.
Note: We are also storing socialIds
in a hash format for security reasons and storing email helps us to know whether the user is a new user or an old user and help to prevent duplicate records.
But there is a problem, there are some providers who are not returning user emails.
So it has become a problem to identify whether the user is new or old, it also creates the risk of duplicate rows.
What is the best way to solve this problem? Is it good to store IDs in raw form in the database?
from social authentication provider is not returning the user email
No comments:
Post a Comment