Database schema for Facebook, Google and my own authentication - database

I want to accomplish nearly the same thing as this question, which is to store authentication data from multiple sources (Facebook, Twitter, my own app, etc.) so that one person can log in to their account from any/all of the mentioned providers.
Following, I posted a screenshot of my two created tables.
The table "identity" will be responsible to store the login method (Facebook, Google or my own login system). An user can have one or more "identity".
In the table "identity", the column "adapter" will store the authentication method (facebook, google, myapp). The "hash" column will store the ID of the authentication method (for Google or Facebook), or if it's a record of my own app authentication method, the "hash" colunm will store the user registered password encrypted with SHA1.
My question is, for example: How can I detect if the user witch is authenticating through a Facebook account don't have already an "user" created with another authentication method? Because I don't want to create multiple users, to the same social auth account owner, or my own app account owner.
Can I get through this using the email column? So I can verify if the authenticating user already have a same e-mail registered in the "user" table, if he has, then I can create an identity with this same user_id?

If it is possible, I would recommend that you add the user before you add the identity id.
Check for existence of matching email before creating the user, then add the new identity.
I would have thought there should be a constraint on the identity that the user exists before creation. Otherwise you risk adding 'Identities' to the database with no connected user at all.

Related

Social account and normal account db model

In my application, a user can signup by completing a form or by using a provider (facebook, google, etc.). The main difference is that the user signing up by form will have a password, while the one using a social account will not.
I am not sure how to deal with the user model in the db. Should there be 2 separate tables, for each type of signup?
There is also the case of linking a normal account to a social account.
No a single table will suffice.
When the user signs up with the form, You save his info with the password he registered, And when he signs with the provider, You only save what the user allows you to save (email,profile picture, etc..).
And regarding the linking problem you can just make an option to merge accounts like here in stackoverflow.

What is the best approach to design database with external users, groups and permissions?

We are removing User, User Group and Permission models from our backend in favor of Auth0.
Our first idea was to just delete User, Group and Permission tables from DB and replace related foreign keys with varchar field. In this field we would then enter IDs that we get from Auth0 in JWT (pointing to something not present in our DB).
Is this good approach? I somehow feel that there must be more "relational" way of doing this.
Generally OAuth will not do all of the permission checks for you. Instead it gives you general mechanisms to sign the user in and issue + validate tokens.
In most real world architectures you also need to manage a second level of authorization in your back end - using domain specific user data for roles, permissions etc.
A couple of write ups of mine may help:
User Data Management
API Authorization
Auth0 Community Manager Dan here,
In this scenario you may be able to leverage the RBAC to replace your existing users/groups/permissions setup.
You would register a user's roles and the associated permissions of each role in the Auth0 dashboard or programmatically via the management API. Then you can setup a rule to add user roles to the token.
To connect this user to your existing user data store you can store the Auth0 id, similarly to how you have described.
This allows you to lookup the user when the token is received, and to associate any permissions or roles the user has. You can make roles API-specific by adding a prefix to the role, or have roles be general depending on your needs.

Separate tables for openid logins

My website has a normal sign up and sign in process now I want to add google login (and later facebook, yahoo and ...) to my website but I'm not quiet sure how to change my user table.
Add all user info I get from google, facebook as new fields to my current users table? each login type gives me a first and a last name I just can keep one of them. the only user info to connect different login types with each other is the email address. So if a user has used different email for his/her facebook account than his gmail then each user will have lots of unused fields.
Using separate tables for each login types. have a google table, facebook table and ... and connect each record with a user in user table (if user has not signed up before google or facebook information will e used to create one). in this case user record will have a missing password field that of course can be resetted from account or by password forgotton function
which one is the correct way to do this?

Database scheme for user logging with different accounts

currently I need to provide web site logging for different social accounts (facebook, google, twitter and so on).
I know that stackoverflow has same system and I wonder if there is stackoverflow database model in public access. So I can find right way to store user data in my db.
Currently I have next problems.
So, I have my table for users:
UserID
UserName
RegistrationDate
Email
Rating
For users who create account with web site form I use next additional info:
Password
FirstName
LastName
Avatar
I stock in question how to store data for users who login with social networks and what should I store.
It seems that I dont need to store facebook name, surname and so on. I thought about getting it with js on pages where I need it.
Also I am thinking how to provide user with adding facebook, twitter references and so on for his profile.
P.S.
I am using DotNetOpenAuth for user authentication via social networks. Working with asp.net MVC 3.
About functionality on my web site:
just adding articles and rating for user.
For comments I use https://disqus.com/.
Ideally, you should have two tables. One for Users and one for Identities. In the Users table, you store things like your application user id, name, emails, etc. In the Identities table, you link back to the person in the User's table, but have a 'network' field that says which network the Identities row is for (e.g. Facebook, Google, Twitter, etc).
The Identities table can store the User ID and details specific to that platform, e.g. User_ID for Facebook, Twitter username, etc. The user will have one entry in the Users table, but can have many entries in the Identities table, depending on how many networks the user has connected with.

Do I need to insert one fake row in database?

I have few tables like example.
Users Books UsersBookPurchase
UID BookId UserId
UName Name BookId
Password Price
Email
This is fine. I am having my own login system but i am also using some 3rd party to validate like OpenID or facebook Authetication. My question is if the user is able to log in successfully using OpenID or facebook Authentication, what steps do i need to do i.e do i have to insert one fake row in Users table because if i do not insert how will integrity be maintained. I mean what user id should i insert in UsersBookPurchase when the person who has logged in using Facebook Authentication has made a purchase because the UserId is reference key from Users table. Please give me a high level overview of what i need to do because this is fairly common scenario.
Thanks in advance :)
Basically yes. Don't think of it as a fake row. What you should do is to create an actual user account based on the data provided by Facebook API (I am not that familiar with OpenID)
Facebook API will provide you with first and last name, email address, maybe some other data
Facebook does not have the concept of login name, users login by email address.
What you do is just create a new user from the data provided by API.
There are some things to watchout for: it is possible that user is already registered on your site. When you get data from Facebook you should search your own user table to see if the email address already belongs to your own registered user and it that case you can do some fancy things like mark that user as also having a facebook login.
If I were to do that, I'd abstracted login info into a separate table and have some sort of type in the User table. The type is used to identify what auth method is used, i.e. your own, Google, etc. If a user does select using alternative methods, you do need to have association but with a different type. But yes it is a new record.

Resources