I didn't make the excuse that it is "easier for the developers"; I stated that most people deploying Web applications don't feel the need to integrate those applications with other authentication solutions, and so they will use whatever is provided. The provided functionality could probably be better, but I imagine that there are more people wagging their fingers than working to improve the situation amongst the many different solutions deployed on the Internet today.
As for integration with identity providers, apart from leaning heavily on Google and Facebook, for it to be commonplace the various solutions would have to be a lot easier to deploy - particularly under the conditions currently experienced by those deploying Web applications - than they currently are. Even the commercial solutions can be dreadful: on one project I was involved in, the large vendor concerned had to get consultants in from abroad because there was no-one in the entire country who could offer the necessary assistance.
With things as they are, I think it is somewhat optimistic to expect people - those deploying applications, of course - to enthusiastically abandon the simplest thing that works for them and somehow hook up their application to an inscrutable stack of authentication components with varying levels of documentation for a technology that, if not properly digested, will have people wagging their fingers once again that the resulting solution is insecure because some aspect of the configuration was not fully understood.
All this reminds me of people trying to fathom why organisations buy monolithic solutions (often not very nice and even rather maintenance-intensive) from vendors instead of piecing together freely available tools. No amount of pointing to "how to" documents and calling people stupid is going to change people's behaviour in situations like that.
Posted Jan 10, 2013 1:21 UTC (Thu) by dlang (✭ supporter ✭, #313)
[Link]
I own a tablet that I can't login to the support site for it, because they have opted to require SSO with facebook, and since I don't use facebook I can't login to the support site.
Whatever SSO source you pick, you are going to run into some people who won't use it.
Open-ID
Posted Jan 11, 2013 15:59 UTC (Fri) by kleptog (subscriber, #1183)
[Link]
Getting Django to work with OpenID is trivial, there's are modules for it.
I used django_openid-consumer and I got it working in an afternoon, and I wasn't even using the integration.
So I think, yay, don't have to deal passwords, lost passwords, changing password, encrypting passwords, etc. And then I get people complaining that they don't want to use OpenID because it lets the provider know that you're logging in, and so they asked for username/password mechanism.
What's a developer to do in this situation? People can set up their own provider, but no. The set of people who don't trust OpenID providers and don't want to setup their own is apparently larger than I thought.
Open-ID
Posted Jan 11, 2013 16:49 UTC (Fri) by pboddie (subscriber, #50784)
[Link]
To be fair, OpenID is a well-trodden path (unlike various other technologies that shall remain nameless), and there appear to be plenty of OpenID solutions, although many of them seem to rely on the same set of fundamental libraries, so that doesn't mean that the technology is necessarily well-understood even if the amount of common experience is considerable.
Sadly, like everything else, the original simple idea has raced away leaving a lot of people to abandon the idea of running their own provider, and it also doesn't help that people who supposedly accept OpenID sometimes reject identities from providers other than the big names because, paraphrasing one explanation I heard at one point, "you can't trust providers you've never heard of before". Obviously, OpenID is just about the identity and not whether that identity can be trusted with anything - something a Google-minted identity isn't going to help you decide anyway. And let us not consider the expanding interoperability matrix and all its accompanying problems.
I think we're going to see a lot more discussion around trust and decentralisation - for example, whether it is prudent to delegate any control over one's identity either by using a big-name service or by running one's own Internet-resident service on someone else's server - as people begin to question the centralised nature of their Internet interactions.