Currently I have a lot of sites those requires login. All logins different with each other. Different user name, different password for each person. Now I'm looking for some improvement, like gmail and youtube. You know after logged in www.google.com, other sites like youtube, mail.google.com etc, they login automatically. How they did it?
There are a few different ways of doing this:
Use OpenID. This allows users to use the same username and password as they do on other sites (such as SO). There are multiple providers for this.
Use Facebook's Auth API.
Both of the methods above remove the need to implement your own form of authentication.
However, if you want to maintain your own user list from a central location, see this thread for information on how to implement this type of system.
Related
I'm trying to work out how to structure a database schema that allows me to have multiple authentication sources for the same end-user.
For example, my web app would require users to sign in to utilize many of the functionality of features of the app. However, I do not want to be responsible for storing and authenticating user passwords.
I would like to outsource this responsibility to Google, Facebook, Twitter and similar identity providers.
So I would still need a database table of users, but no column for a password. However, these are authenticated would not be my concern. But I would still need to somehow associate my user with the identity providers user id. For example, if my user signs up with Google, I would store the users Google ID and associate this with my user. Meaning next time the user makes an attempt to login and is successfully authenticated at Google, I would make an attempt to find any user in my system that has this associated user id.
I've been trying to look for some common and recommended database structures, with no luck. Maybe I'm searching for the wrong terms for this because I cannot imagine that this is an uncommon way to do it. StackOverflow seems to do something similar.
The way I imagine it, it would allow me to associated multiple authentication sources for one app user. Meaning once I've signed up with Google, I can go to my settings and associate another account, for example, a Facebook account.
How should I go about achieving this in a flexible and clean way?
Thanks.
You need to know what data you have to save in your db to authenticate a user with a third party login.
For example, once I used Google to login users in my app, I save Google user id first time a user logs in and get data the next time.
You could have an entity with third party providers, so you will create a table with 2 values, user_id (your user data) and provider_id (Google, facebook, twitter...).
If you are going to use just one provider then you could add provider_id field to your users table.
I'm trying to create a website to authenticate users through the use of a throwaway password where the assumption is that the user might not use the website again (basically a one time access).
I have done my research on OTP and various solutions to authentication but these don't seem to fit my requirements, most of them seem to rely on users having login credentials to the website whereas my system would allow them access without the need for registering.
The implementation of passwordless authentication by Auth0 seems to fit what you're describing. Even if you were not considering a third-party provider it may be useful to go through the documentation.
Basically, a user can login to a site without any need for a sign-up process. They can do so just by requesting that a one time code is delivered to them, for example, either by email or SMS.
This way, they can get quick access without having to setup a user and in the event that they do come back your application can recognize this because they will most likely be using the same mechanism, that is, you can use the email or mobile phone as the unique identifier.
Disclosure: I'm an Auth0 engineer.
If you do not require your users to register, why do you need authentication at all?
Why not just set a cookie with an unique identifier on the first visit? You can store data at the server side associated with that identifier. Keep track of when you last saw the user, and if they do not return within a certain period, you can delete any data you stored for that user.
I would like to know how does the login procedure work in the Internet sites (e.g. Gmail). I am trying to implement an online application which I want to secure with user authentication.
Could someone give a detailed explanation or point to a relevant site
Many websites use OpenId to allow users to login. OpenId uses OpenId Providers (such as Google) to login. One big advantage is, you do not have a password for the user stored (so if you get hacked, it can't be leaked). Some info: http://de.wikipedia.org/wiki/Openid
ASP.Net has the concept of Membershipproviders, which can in turn use many different ways. See here: http://msdn.microsoft.com/de-de/library/system.web.security.membershipprovider.aspx
There are many ways (another may be OAuth) to create a login, I think you can't talk about one single correct way.
I have a website and I want to accomplish the following:
my site's server is able to uniquely identify the viewer of the website (assuming he is currently logged in to FB). NOTE: I don't need any personal information. I just need to know that he is unique. So if he comes back again tomorrow, I'll know its him.
based on this unique identification, store data in my website's database about his actions (eg. he uploads something etc).
my site should also be able to know if he has "liked" an item on my website.
A) Is the above possible at all?
B) If Yes, is it also possible that my site doesn't use "facebook login" for my site, and still achieve items 1 to 3 above? My understanding is that users can "like" and "comment" (using the social plugins) without the need to explicitly "FB LOGIN" on my site.
Reason for my asking question B is that I want to make using my site as seamless as possible (ie. don't have to "ask" users to give app access to my site to their information)
A) Yes
B) No, it is possible with the facebook API to add simplified user sign-in and registration. A user will still need to confirm/allow the link to be made.
You can find more info here: https://developers.facebook.com/docs/guides/web/#login
Funny thing, StackOverflow uses several of these APIs for it's users...
All I want is a persistent membership system and easy registration/login process for my several social applications.
I don't really need their e-mail addresses or personal information.
However, I don't want to convert my websites into an anonymous board or spamming area for bots, etc. and I don't want to force my visitors to login through their Facebook or Google accounts.
What do you recommend in this case?
Thanks.
You can't have it both ways. Either you want an anonymous site or you need some type of authentication/identification.
There are several easy options for authentication.
E-mail only. You can do authentication with e-mail only and cookies, no password. This isn't common and is often used in addition to passwords for high-security scenarios, but can be used without passwords for even simpler security. Basically have users log-in with their e-mail only. Then send them a confirmation mail and they click a link in the confirmation mail. When they click the link, store a permanent cookie and from then on they're authenticated. If they loose the cookie, they can repeat the process and authenticate again with the same e-mail address. No manual account creation, no passwords. It's really just as or even more secure than using a password. It's a little cumbersome though to get an e-mail to login, but hopefully cookies will not be lost. Several of my banking/credit card companies do this in addition to e-mail and the only time I notice is when I change computers.
E-mail/password. Don't downplay the usefulness and simplicity of a email/password authentication. Users are accustomed to id and it works fine. As long as you have it isolated to a single small form to create an account, it won't really get in the way.
OpenID. I believe all public website should support OpenID as an available authentication mechanism. For people and sites that use it, it's wonderful. Simple authentication and easy to use. Setup is painful for people that don't know what it is or how to use it, so I wouldn't recommend using OpenID only except for techie sites, but it's a great alternative.
I'd suggest you to use OpenID authentication on your website. This way, you need not to worry about the hassles of storing and retreiving user data on your server plus offer the facility to user to use thier OpenID login credentials for your website.
Kimd regards,
Dorcy