I have been given a task for implementing "User authentication through Google Apps account", in our custom php web application. User should be able to login both directly, or using google account.
I am trying to use openID for this. I have read about openID and found following:
In our existing users table, we will add an other field 'openid_identity'. While login, we will send Google login and password to Google and get response. From response, we will get user's identity and then by matching it with the identity in database, we can get user details.
One thing that is not clear:
In our application, admins can create users. Users can then login with their email (like john#myapp.com) and password.
Initially, before using Google sign in, our user's table 'openid_identity' field will be empty. How can we handle OpenID login for first time? What do we show to user? A 'signup with Google' page? If user signs up with their Google mail (like 'john#gmail.com'), how can we know which user he is, from users table?
I'd suggest to implement another table to handle external login methods instead of adding a field to your current users table. This "one to many" relationship will help to make your application more flexible: one day you might be asked to add support for Twitter, Github, Facebook login too.
I guess that you are planning to modify your login form to present different login methods, let's say the classic login form and a "Login with Google" button.
Then I think you should plan this case: when the user authenticates with Google, the Google Api will return the user's email and you'll check the external login table to see if the record is already there.
If there is no record you start the user subscription process as usual but you can pre-fill user's data with what you've got from Google. You'll save both the record in the external login table and in your common users table keeping them related.
If the record is already there then you'll consider the user as authorized. You will have to adjust a little your current authentication process.
Talking about flexibility, eventually, while you write your code, you can take in consideration the idea to allow each user to authenticate with more than one account and more than one external service.
I also would consider to use this composer package https://packagist.org/packages/google/apiclient to deal with Google's Apis
Related
I need to add social login to a site that already has a user system that is very simple it only stores an email and a password and that's about it. I need to add facebook and twitter login options but I am facing a difficulty figuring out how to integrate that with the current system because it has an unique index at email so when a user tries to log in using a social account I first get their details and check if that email is already registered, if not then I register them automatically and then log them in and subsequent login requests find the email and log in the user automatically.
The problem comes when a user has been registered through the ordinary registration form, then I could create a fake social media account using a given email and could then log into a user's account on that site simply because they didn't have a social media account using that email.
I suppose I could add a column "regMethod" that would indicate which registration method was used and make that a complex unique key (email, regMethod) and have 0 be the native form, 1 facebook, 2 twitter and compare that when logging a user in but that seems rather hacky to me. Also if a single user uses all login methods for some reason the will have a number of accounts and not just a single account which is a problem.
I am pretty sure there must be a better solution to that problem and someone has overcome it already so I feel like I would be reinventing the wheel trying to solve it. How is this done in reality?
A simple possible solution to your problem I've been using for a site that allows different types of login (local or with a facebook account) was to seperate the user account data from the authentication data by having seperate tables for them.
First I had a table for the user data. You would then have two tables for possible authentcation, one LocalAuthentication containing anything related to you local authentication method like salt, password hashes etc. Then you will also have the table FacebookAuthentication and it only needs to contain a facebook access token. Both of these tables needs to reference the UserTable.
That way a single user could have multiple authentication to the same account.
just add facebook_id and twitter_id to your users table. Then
you'll have two choices :
Each social account is a new account (no merging), you just have to create and persist a new user object.
Once logged (classic way : login / pwd), you provide to users the ability to link their account with social accounts. In that case, you have to update your user table.
Dont forget to store the facebook_id or the twitter_id you'll get when the users uses the API.
I've done a database schema for user management alongs with their roles and permissions. The problem actually began, when I decide to integrate a multiple "Open Auths" such as Facebook Login, Google Login, etc...
My database table DB.USERS looks like this at the moment:
id
oauth_id
username
email
password
remember_token
...firstname,lastname,etc...
At the moment, problem is, whenever user tries to login via one of the OAuth (Google, Facebook) and there is an email already taken (either by one of the oauths or application's auth library), it triggers an error and cannot proceed.
I wonder what's the best approach to create a database schema for such method ? Anyone who already have an experience with it ?
I'm using a Laravel 4.2
It is an entirely normal situation that the same email address is reported by different social login sources. First of all you need to answer a question - what do you want to do in such cases?
If you trust the social login to report a valid email address, you could simply merge new login source into an existing account.
You could also choose to create separate accounts for each separate login source - in such case you should treat email similarly as a name - without requiring it to be unique. This is problematic if you want to allow email+password logins on your own.
Another questions to consider:
What happens if email address reported by social login changes for an existing account? What if new email matches another existing account?
Do you allow users to change email proactively?
Design the process first and then use a suitable DB schema.
We have our own registration and login system.
Many of our users are users of facebook and often forget login details to our site so it would be good if they could login to our site using their FB account.
What would be the simplest way to associate their FB account with their user record in our system.
I guess there is no way to avoid a double login for the first time? i.e. login to facebook, then login to our system so they are paired so to speak. We store their facebook id in their user record and future visits would only require a FB login.
Any opinions or suggestions very welcome.
There could be various solutions suggested for the scenario mentioned, few could be as follows:
I hope you currently have an Email field in your database, just add another field to store FB id.
Provide an interface in your application, where logged-in users can associate their facebook account with their account in your application.
For not logged-in users, you can fetch email address from FB, and do a quick look-up if the email already exists in your system, and if it exists you can update the FB id field in the DB.
If its the other way, email doesn't exists, you can add a new account into your user table.
i think OAuth Library from Philsturgeon's can help you to solve your problem check this library
OAuth
also check documentation of this here
Oauth Doc at Spark
First of all let me start by saying that this question is not about different openID and oAuth implementations. There are many classes about these.
My question is what to do after authenticating a user:
How to add this user to the user table in the database?
How to handle different logins for the same user? (Remy Sharp's example suggests
something for openID)
How to combine oAuth and openID in the database?
Any ideas?
Your question has to main parts to it:
Authentication
Authorization
Usually the two are not treated differently if the identity provider (IP) is your own, which has been the most common setup in web apps until now.
When using an OpenId Provider such as Google, the authentication part is seperated from your control. You will get a token back telling you if the user is authenticated or not. The token will normally contain the following claims: Name, Email and Named Identity where the last is the unique id of the identity at the IP.
So far so good.
The trick is now as you ask, how do I authorize this user?
well, there are a couple of approaches to this.
First off, when you create a local user in your system, you can prepopulate the Name and Email values based off the claims you get from the IP. In this process, you can start and say that all users that have a profile stored in your system are authorized, or you can develop further processes that will add whatever details you need to know about the user.
Then, how do you avoid that the user is not re-registered if they switch from google to facebook as the IP?
This is where things get tricky. The most common claim that Google, Yahoo, Facebook will provide to you is the email address and Name. So what you can do, is try to match the incomming claim with existing customers in your app. This is not failsafe however, as people can have different emails in different systems.
The name value is also not safe.
In our setup, we start by matching emails, as we know that most IPs validate email addresses. This will reduce duplicates a lot. After that check, we start our own validation process where the goal is to see if the person is already registered. This process looks for the customers mobile number in our database, and if a match is found, we send a one-time-password to the customer to verify correct ownership of the phone number.
Since login is a time sensitive setup, we are created a simple SQL table that maps external identities to our customer numbers. This allows us to implement this kind of validation logic outside all our web apps (and thereby reduce code redundancy)
The most simple way would seem for me, to have a basic user table, where you add the user at register and have a extra 1:n table where you save possible authentications. Maybe you need more than one table, if there are methods, which need way more columns than others.
I implemented login via OpenID from google and met similar problems. I used openid library from janrain.
I don't created separate table for openid. I used secondary emails instead (secondary emails are stored in table of users).
While logining through google it's possible to demand user emails (I believe there's the same oportunity in any other openid provider). After I get response from google that user is logined, I look in table of users. If provided email was found in table (it doesn't matter whether it's primary or secondary) I login the user. If the email is not found, I ask user whether he has an account. If yes, he is proposed to login with existing login/password, after that I add secondary email to user. If the user doesn't have an account a new account is created.
So you don't need special new tables for these tricks.
I have a problem of thinking of how to integrate 3rd party login (also do silent register) on website where already is used regular login/register system.
Basically current login is quite regular:
As user enters website session
class determines if he need to
re-login.
When user login all kind of sessions and cookies are set and
user get access to restricted areas.
Users table in mysql has quite a lot fields also password fields.
What i wondering is how you create user entry in the same database table if it's not there and do full (silent) register for that facebook user.
Well i'm not sure what you mean by silent register, but you can simplify your regular signup process if the user is connected to Facebook.
This is what we do:
When a user comes to our website (unauthenticated - no cookie set in browser), we check to see if this user is connected to Facebook
If the user is connected to Facebook and has connected before, we "sign them in" to our website
If the user is connected to Facebook and has not connected before, we do a call to the Facebook Graph API to grab some user details (name, email, etc), redirect the user to our signup page and fill in most of the details using the Facebook info we just received.
We have a seperate database table for Facebook users - we store the Facebook Unique ID and the user's email address.
The email address is very important - this is what we use to perform a single sign on, as the user's Facebook email address should match the email address for the website.
OpenID is a safe, faster, and easier way to log in to web sites.
:D
use open id ...
there is many lib in this address http://wiki.openid.net/w/page/12995176/Libraries
each user can login with user in facebook and gmail and you must give each user id and relation models for access
I am also new to this but got some idea how to do and i would like to share it.
You can use the Javascript API provided by Facebook, Google+ etc to make login into the site. The API has in-built methods which invoked for authentication and pulling data from the user's account(which is customizable what user data to pull). In between the javascript code you can write ajax call to your server script with user data(got from the third party server) for making the user signup or login into your system, what ever want to do.
Yes the configuration of all these are bit headache :-(