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.
Related
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?
I have a JSON REST API written in Symfony 2.7, and I want to authenticate & authorize users. This is my first time doing this, so I have some doubts/questions.
For that, I thought several methods:
User & password, and then save a session in the back end
Same as 1), but add an "apiToken" (randomly generate when user register) and then sending back & forth the apiToken in every single request to check user identity.
Use OAuth (which I'm currently reading about it).
I read that using OAuth for a simple API is like an "overkill", but on the safe side it sticks to standards and also allows me to use it when using my API with mobile devices and different platforms.
Also, I don't know too much about security flaws of using method 1) or 2).
I know this is maybe based on opinions, but I don't know any other site to post this question, as Symfony official mailing was shut down and migrate here it seems.
As you seems to know, your question is too opinion based.
If I can give you some advices (too long for a 600chars comment),
OAuth is powerful, but so much free.
I mean that you can easily implement it sort as everything works well while having a set of potential security issues without being aware of their existence.
Libraries and bundles providing OAuth are hard to maintain because of the new security issues regularly found.
On the other hand, if you need the benefits of OAuth (be a client and/or a server, compatible with the most part of social networks), go learn OAuth and do your experience with it.
Otherwise, use a simple credentials/request token two-step authentication.
See the JWT Authentication tutorial by KnpLabs,
Symfony Guard Authentication by Ryan Weaver,
and the great LexikJWTAuthenticationBundle, easy to implement and to use.
We have a large high traffic site with a lot of data on it (similar to Kickstarter), and we want to provide to our content/project creators a means of pulling their data from our site via an API.
Someone suggested I use OAuth, however my experience with OAuth is limited to setting up a twitter datasource.
What I want to do
Provide a user an Application ID and a 'secret'
Allow this user to connect to our application via an api endpoint, authorizing themselves using the api ID and secret
Once verified, allow this user to pull only their data from the application
The data that a user can pull: votes they have cast, pledges they have made, purchases they have made, projects/ideas they have launched, data about those projects/ideas (votes/purchases/orders/cancellations etc)
My question is:
Is OAuth overkill?
Is there a better way to handle a user/users website to connect to our API and pull/verify certain data by using the API we make available, while requiring each incoming request to be authorized for the user/site initiating that request.
Ideally, we will have an endpoint that is accessed as:
https://api.oursite.com/request/params
We want this to be as simple as possible for our users that wish to implement this interface. Thanks for your help!
Generally it's OAuth, in combination with SSL. That's the standard and is likely to stay. Before we saw also logins: username + password to access an API but that's becoming less and less.
So the suggested way is OAuth. There are no serious other solutions yet. To make it easier to adopt your API you could release some classes in some development languages so developers can have a quick start. You could start releasing those classes at for example GitHub to raise adoption of your API and get a quick access to developers. They might, if you do well, even start improving it.
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 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.