I am working on an app that will work best if connected to Apple/Google accounts (to work with photos) but does not have to. It will have login with Google/Apple/Facebook/tbd (different regions). I think I can safely ignore people who don't use any popular social services (they are not likely to be interested in my app's functionality).
Is there any point in implementing custom email/password authentication? That means database, password recovery, etc - a lot of added effort and quite some extra risk.
Personally I always prefer those social logins. They allow me to control what I share with the app, I do not have to remember a separate password, etc.
One option is to use a third party identity provider like Auth0, then you can both provide username/password and social login through them.
Personally I often prefer username/password , as I don't want the big giants to have analytics in every thing I do. Also to keep the services more apart. Yes, social login is convenient, but at what cost?
Related
I know design is subjective. But I wanted to know if this is a good idea?
Suppose I implement OpenID connect in my application. I support sign in through multiple platforms. But now, suppose I need to maintain a database of my users for authorisation of resources on my server; or let's just say I need to store user preferences.
Is it a good idea to maintain a user's table and push data into it every time a user signs in using OpenID, or using my sign up/sign in API, using email ID of the user as the primary key (since that doesn't change) provided by OpenID?
What are some good ways to combine the two? What are some pros and cons of this?
What are the best ways to support authorisation (of resources on my server) along with authentication using OpenID/oAuth?
It is a really good question and not covered well in many places.
TRACKING USERS
In terms of sign in via multiple platforms a common pattern is to use the same authorization server for all types of login and 'federate' to different identity providers, with the following benefits:
Simpler code in your UIs and APIs
A single user id per user regardless of the sign in method
USER DATA
In the real world of business apps you often need to manage users and authorize requests via 2 sources of user data, as you indicate. A couple of my articles may provide some useful techniques:
User Data Management
Authorization Design
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
I have a request for implementing a login system using local credentials + openId + facebook-connect.
So a user could sign up/sign in using any of the 3 possibilities.
I think that allowing OpenId AND facebook connect adds some flexibility, but in other hand adds some restrictions since you have to integrate all different logic and make existing differences transparent for users.
What do you think? Any good reference for managing federated login using both external mechanisms? Any well known site doing it right now?
RPX lives to take care of the complexity for you.
But if you've made your system able to do any two of the three auth methods mentioned, adding the third isn't that hard. You've probably already got all the necessary abstractions and workflow elements done.
As for who's doing it... seems like a fair portion of the OpenID-enabled sites I see these days have Facebook Connect too. I'm not sure which count as well-known... I guess you could browse RPX's customer list.
I have to start a new project where user authentication/management will be required.
A lot of websites use existing authentication mechanisms like facebook/twitter/openID/google/etc (even SO).
While I might understand that they are used to simplify some parts of this workflow can someone enumerate the pluses and minuses of using one of these authentication mechanisms vs. an usual user creation and what should I look for when I do this?
Thanks in advance!
Here are a few:
Advantages of using external auth (like openId)
For the user, fewer account names/passwords to keep track of
For you, don't have to manage password resets etc.
Disadvantages
Ties you to an external service (if google/facebook is down, so are you)
Your site is only as secure as the external site(s) you trust as id providers
I wrote an application recently, which relies on OpenID for authentication. A lot of web applications these days are moving to OpenID, insofar that they already have userid/password authentication scheme, and OpenID is just an add-on. Since my application is a new one, I decided that it makes no sense to program separate authentication mechanism based on userid/password, when I can rely on OpenID for all the authentication altogether.
But sure as hell, once I presented the application to a customer, she asked "well, how do we create user accounts, and reset their passwords"? Conceptually, she didn't want to make the users create their own OpenID if they don't already have one.
I kind-of had a pre-made response to that, which was: "You can always run your own OpenID server". I guess I didn't put too much thought into this answer though, since many implementations of OpenID server are pretty raw and need a lot of work before they could be run in production.
So, my question is: does anyone here have an experience of running private OpenID server purely for authenticating of her own users. Here are the features I'm looking for it to support out of the box:
Ability to bulk-load user accounts
Self-served password resets through verification email
Administrative features (lock/unlock/disable accounts, troubleshoot, etc)
Presentable look
This doesn't directly answer their question, but how many folks are on the internet and don't have an account with Yahoo, Flickr, AIM, WordPress, Myspace, Google, or MSN? They're all OpenID providers.
I'd argue that for the tiny % of the 'net population who uses none of those services, just point them to Vidoop or MyOpenID and let them get an account with someone who already has a secure infrastructure.
This was my thought initially... But the application is for non-internet-geek type of users, so the expectation is that they may or may not have any of above mentioned accounts.
Another thing is: MyOpenID gives a neat, nice URL for you, when Yahoo (for example) doesn't. Even if you know that a person has a yahoo account, you can't just use username.yahoo.com. Google is same thing - you must first use your google account to activate a blogspot account, and then you have an OpenID, which may or many not correlate to your gogle id. So, if you have a list of users and even if you know they are all on google or yahoo - even then you can't make assumptions about their OpenID url
there are ready to use frameworks.
you only need to put them together. this can be fast done.
you didn't wrote about your platform, but if you like to use php then a look at "zend framework" or "php openid"
I'm using OpenID in my own applications but if I was to go to a customer and they raised the issue about having the passwords and stuff, I'd probably just tell them that the providers would handle that for them. If they didn't like that idea, I'd charge them the extra hours that it would take to setup the membership system. That way you get to charge more and you have a happy customer. I don't think the general public will grok OpenId for some years to come.