I published Why Federate? last week, arguing that apps should get out of the password business. Ouch! I got ferocious pushback in my comments, on Twitter, and on the accompanying G+ post. Take a minute and read a few. Clearly we need to have a conversation.
So nobody likes federation? · It’s not that bad. First, my readership is impossibly geeky, way out on the edge of all the curves. Second, there’s a big difference between talking to app builders and app users. Third, even given all that, I got twice as many +1’s as negative comments.
But I’m not going to pretend I wasn’t surprised; among other things, I hardly ever hear this flavor of response face-to-face.
The conversation · A few nay-sayers are in tinfoil-hat territory (“OOH EVIL COARPORATIONZ”) but I think most of the issues people raised are substantial. Having said that, I still think federated identity is a good idea.
So I’ll take up the issues one by one and give each the space it deserves. In the rest of this piece I try to summarize them, with two goals: First, this is going to be a series of follow-on pieces, and it’ll need a table of contents. Second, have I got all the big ones? Please comment or email or whatever if there’s something I’ve missed.
OK, here we go. [Note: I’m going to be quoting a few commenters; in most cases I’ve done some editing for style and punctuation and so on.]
“I’m not sure what’s happening” · Quoting from commenter Pedro Oblamar (not his real name): “When I see a ‘sign in with Facebook’, ‘Sign in with Google' button I never click on it, even if I have accounts with those sites. I am never sure what the implications of signing in through a third party are: will this website show up on my Facebook ‘profile’? Will my presence on this website link to my Facebook account?”
For a deep-dive on this, with really a lot of detail, see FC1: Who Learns What? Then there’s the whole notion of “social sign-in”, which produces strong emotional reactions; I’ve tried to cover that territory in FC9: Social Sign-in.
“I don’t like being tracked” · Commenter Chris Carter: “When you use a 3rd party IDP like that you are giving them information about the behavior of your users – which they are free to sell to anyone, even your competitors.” Commenter Martin is punchier: “FB and Google tracks the hell out of you.”
Well yeah, and the spooks track more, and real actual criminals try too. Check out FC3: Who’s Watching? which tries to cover the big picture of who’s tracking you, what they can see, and what you can do about it. There are things that worry me a whole lot more than commercial tracking, but it’s not insane to worry about.
“I don’t like you” · Some people just don’t like certain Big Internet Companies. Commenter Dewald Reynecke: “I don't trust Facebook/Google as far as I can throw them – I simply do not want to outsource my identity to an advertising company.”
Fair enough, and trust has to be earned. I think the question of who individual people (and IDPs, and RPs) ought to trust is tricky but tractable; FC8: On Trust proposes a couple of checklists to help think about these things.
I’m unconvinced that being in the ad business is an instant ticket to distrust, but people are going to make up their own minds about that.
“I don’t like spooks” · Commenter Gavin B: “Federate using FB, G+, Tw? Guess what, they all bow to the USA/NSA.” Commenter brejoc: “Right after Prism and Tempora this is a very bold statement.” Commenter Daniel Serodio: “The NSA has made your job much more difficult.”
Well, I don’t like them either. In FC3: Who’s Watching? there are lots of details about not just the spooks but everyone who’s watching you; what they can see, and so on.
One of the key points there is that, while big Internet companies are prime targets for snoopy public servants, we’re also pretty well lawyered-up, compared to the vast majority of sites and apps up there. So the trade-off isn’t simple.
“I like Persona” · Lots of people said that Mozilla Persona would be a better basis for federated identity than the OAuth2-based OpenID Connect.
Having taken the time to do a partial (but I’ll finish it) integration with Persona, I was left impressed, but with open issues percolating in my mind; see FC4: Persona Questions.
“I forget which provider” · Commenter Jashan: “Users tend to forget which of the gazillion available services they have registered at your site with. And then they're too lazy to try all the possibilities. And then they're gone.”
This one is tough; we can all agree that we want to minimize the cognitive load on anyone trying to get signed in to our software, but it’s not obvious how best to achieve this. Putting up an unstylish “NASCAR page” full of IDP badges may be less friendly than asking people to just remember their account details; but maybe not. Fortunately, work is in progress on some good alternatives; see FC6: Who Are You?
“I like password managers” · I mean something like KeePass or LastPass or 1Password. Commenter NH: “I use a password manager to auto generate random passwords and save them, which, while being a bit less handy, makes me feel better at least, knowing that there isn't one single site/password that, upon being compromised, gains you access to everything.” [Disclosure: I use 1Password myself.]
To which I say “Yes! Please start using a manager”. But there’s more to it than that; FC5: Manage Those Passwords! surveys the landscape. At the end of the day, I don’t think these things (good though they are) really weaken the case for Federation.
“You’re a big target for the bad guys” · From commenter Daniel: “What if Google/Facebook/etc. get hacked? Then the bad guy has all the login info for every site I used them to login to.”
For a deep dive on this issue (and the next one) see FC2: Single Point of Failure?
“You’re a single point of blockage” · Nik Clayton on G+: “And what happens when FB, G, or others decide to close the account you’re using... Now you've lost access to a lot more than your G+ feed.”
For a deep dive on this issue (and the previous one) see FC2: Single Point of Failure?
“I’m a user not an operator” · Gary Royal on G+: “Federated login has a clear benefit to the service provider (access to disaggregated user data, particularly that user’s social contacts), but only an ostensible benefit to end users (freedom from having to remember yet another password), so on that level it's purely a swindle...”
If Gary’s right, this conversation is a waste of time, because it’s just not reasonable to ask for something in exchange for nothing. FC7: Users vs Apps digs into these issues and tries to figure out what value is exchanged and who comes out ahead.
“I’m struggling with the API” · Commenter Michael Schwartz (of Gluu): “For federation to work, it needs to be easier for web developers. Asking developers to implement OpenID Connect is not the answer for everyone, although with better high level libraries, this will hopefully become easier.”
Does that about cover it? · Write in with any I missed.
Contributions
Comment feed for ongoing:
From: Grahame Grieve (Aug 06 2013, at 22:10)
There's systems which are internally federated as well. Federating the authentication may be difficult for both technical and policy reasons (we've discussed this before - how far can you share an OAuth token on the server side?)
(see http://www.healthintersections.com.au/?p=1554)
Also, from the server side, what happens when Facebook or Google cut you off (or hold you to ransom)?
[link]
From: Janne (Aug 06 2013, at 22:14)
"I don't mind federation in principle. But I don't want my identity controlled by a legal entity based in a foreign jurisdiction, and that doesn't follow the local privacy and consumer laws where I live."
[link]
From: Peter Phillips (Aug 06 2013, at 22:49)
Your list has a lot I'd like to hear about.
One additional concern I have: "It isn't Federated". Within reason, will the "big" sites (Facebook/Google+/Twitter) accept OAuth login from other providers?
If not, it simply seems like a way for the big sites to exert control over the little ones. I'd be much happier if my login identity was controlled by a third party of my choosing. But there isn't much benefit if is only useful for the little sites.
Dogfood-ing, I suppose. But for the big sites, I mean eating the dog food, not just providing it.
[link]
From: Nick Radcliffe (Aug 07 2013, at 00:03)
A variation of the "single point of blockage" is that you are also in trouble if you decide to leave the service you're using to sign into others. Not everyone chooses to stay on Twitter (or even Google) forever, and sometimes it's hard to predict which ones you might later decide to leave.
[link]
From: Paul Morriss (Aug 07 2013, at 02:21)
There are issues of levels of assurance - can we let staff use their FB/Google login on our internal system when we can't be sure that they are who they say they are? I'm hoping things like the UK Government identity provider, which will have a high LoA will open things so people can use that identity.
[link]
From: Hanan Cohen (Aug 07 2013, at 03:19)
Follow up on “You’re a single point of blockage”.
Sites using federated login should notify users on alternative ways to access their account.
[link]
From: Dave Walker (Aug 07 2013, at 04:21)
One I've come up with, recently: "What about migration?"
In part, this is an extension of "I'm struggling with the API"; if an existing site with a bunch of registered users wants to move from a non-federated to a federated model, they'll need to do an ETL exercise to move their users to the federated provider - and doing this seamlessly while maintaining service, is a Big Switch to throw (with attendant risk). There's also the matter that they'll lose users, for one reason or another covered above - no matter how nicely they couch it, they can expect much wailing and gnashing of teeth from their user base when they effectively announce "we're moving your account details to this federated identity service, and you, our users, can't do anything about it" for the various reasons you cite in your post.
Further - and this is a likely problem stored up for the future - there's the matter of what happens when a sea-change in digests happens, such as when MD5 was declared weak and lots of organisations took the sensible step of migrating (and in Germany, documents which had to be hashed for compliance reasons and which had been hashed with MD5, had to be re-hashed). In the event that current commonly-used digests get deprecated, who dictates when digests of passwords or other credentials get changed? What happens if a site in one jurisdiction is federated to an IDP in a different jurisdiction, the site's jurisdiction mandates hash algorithm changing a la Germany, and the IDP's doesn't? It's one which needs to be checked-for in terms of service - and I also note that while federation currently works just fine technically, one of the common reasons I hear about it isn't done more widely, is down to disageements between each company's lawyers about who shoulders the liability in the event that Something Goes Wrong (such as a security incident at the IDP)...
[link]
From: Dave Walker (Aug 07 2013, at 04:45)
A quick follow-up to my earlier comment...
So - modulo questions of liability, lawyers and migration between hashing algorithms - it does make sense for a new service to start out with a federated identity model for the reasons you state, as its users know what they're signing up to, from day 1.
However, existing services have a much harder job justifying moving from a non-federated to a federated model, owing to the issues above, plus anticipated user objections for the reasons in this post, plus migration risk, plus migration project workload (mostly the "T" bit of ETL, especially if they've made earlier application decisions about storing non-standard user properties in their local directories) plus the "it ain't broke, why fix it?" argument...
[link]
From: Charles Miller (Aug 07 2013, at 07:59)
I find federated identity is a good idea in theory, let down by terrible, terrible implementation.
I recently wanted to post a comment to Scientific American's website, and they had an assortment of different identity providers I could use to register.
If I wanted to identify myself using Google+, I was required to give Scientific American permission to "manage my Google contacts". If I wanted to identify myself using Twitter, I was required to give Scientific American permission to post to my Twitter account on my behalf.
At that point I gave up.
This experience is the norm, not the exception. It is so rare that I come across a site that _doesn't_ ask for a grab-bag of permissions that do nothing to help it establish my identity or perform the action I want to perform on the site, that most of the time now I don't even bother attempting to register.
[link]
From: Michael Zajac (Aug 07 2013, at 08:46)
We don’t trust anyone.
We don’t trust foreign governments because they bug us, our own government because they lie about bugging us, the big providers because they are in bed with government, nor little providers because they will get bought or shut down.
I’m a hypocrite because I use Twitter logins for the convenience. But any solution that relies on trusting these organizations will never seem like a real solution.
[link]
From: Caleb Powell (Aug 07 2013, at 09:06)
My two concerns about using Google/Facebook/Twitter/... as identity providers:
1) Their business model is based on advertising. Storing my list of applications/sites with them is a little uncomfortable (of course, I already do...).
2) If I want access to Google/Facebook/Twitter then I need a minimum of 3 identities because these services don't support federated identity themselves. As Peter Phillips mentions in his comment, you should be prepared to eat your own dogfood.
[link]
From: Josh Frankamp (Aug 07 2013, at 09:40)
+1 for Charles Miller's comment. This is a huge negative for federated login. The implementations in the wild very often don't allow the user to say no to the additional perms, it's ID + perms or nothing _even_ when they also provide password based ID.
By itself that demonstrates bad faith from the get go. At first blush you could say this is the implementer's choice, but this is an intentional design decision by the providers as well.
[link]
From: Jack Repenning (Aug 07 2013, at 10:39)
The biggest obstacle I've faced is having my own InfoSec people use the "what if Facebook gets hacked" objection.
We (several companies' experience, summarized) seem to sell federation fairly easily for social services, but not so much for paid services.
[link]
From: Brutus Kir (Aug 07 2013, at 13:21)
A couple more things:
1) Additional point of failure: if a user's authenticator is down they can't log in to my site.
2) Additional complexity: there are a lot of moving parts in federating authentication. In contrast, uniquestring+password is simple, widely understood and there's not much to go wrong. When things do go wrong, the user can generally resolve it for themselves (reset password etc.). More complexity means more confusion which leads to more support being needed.
3) Loss of control: control moves from the user to the identity provider. Advocates see this as a benefit because some people are incompetent at managing their passwords/logins.
I wonder if someone will build a federation-equivalent of mailinator: i.e. an on-demand provider of throwaway identities. Perhaps it could just issue a random token whenever requested, so each 'login' would be one-time only. From the user's point of view it would be equivalent to bypassing the login screen, at the cost of losing state at the end of the session. From the website owner's point of view it would be good for inflating user-numbers, but not much else...
[link]
From: Daniel Serodio (Aug 07 2013, at 15:00)
Please address my previous comment about the weak password hash Google is currently using.
Also, "which IDP did I use?" is very common for me.
[link]
From: John Roth (Aug 07 2013, at 15:43)
After thinking about it for a while, my objection boils down to one word in the phrase "an identity provider": an.
The article "an" presupposes a single provider, which creates a single point of failure. The Mozilla solution provides for a backup provider, but you don't get a choice of which one.
I think most of the issues would go away if the final solution allowed any mix of multiple providers <i>and</i> an identity token that was absolutely, for sure and certain, was guaranteed to never go away. Ever. Even after you had died.
[link]
From: Kevin H (Aug 07 2013, at 17:28)
As someone who's job requires me to have somewhere around 60-80 commonly used passwords and over 500 passwords in total, you would think I would be all for federation.
But in fact, I expect that in the ABSOLUTE BEST case, it is conceivable that could get reduced to 25 commonly used passwords and 100 total passwords in the next 5 years if federation really took off.
And the thing is, that is still too many passwords to keep in my head, so I'm going to need a reliable and reasonably secure system for managing my logins even if federated login is an unprecedented success.
That alternate system for managing logins will work with or without federation. So, tell me again why I should bother getting on the federation bandwagon?
[link]
From: David (Aug 07 2013, at 17:44)
Let's bit the bullet on Public Keys.
You provide sites you want to log into with your public key along with whatever extra information they are asking to collect. When you want to log in, they encrypt a random string with your public key. You decrypt it and send it back; if it matches, you're in.
You need to know the pass phrase for your private key -- but just that one pass phrase; and you have to have your private key and something running locally to decrypt.
Less issues with certificate authorities: I provide the public key when I sign up saying who I am. Optionally, you can compare that key with what a keyserver says is my key.
Better still, ask Schneier to comment on the current state of federated ID; his reputation is not as dinged right now.
[link]
From: Hugh E (Aug 08 2013, at 06:41)
Would you use a federated identity to login to your Internet banking site?
[link]
From: Peter Bengtsson (Aug 08 2013, at 07:12)
Years ago I built a site with 100% federated login.
Apparently Google is the most popular
http://kwissle.com/stats/login-method
I added Persona much later and haven't added it to the graph. Site is no longer maintained.
[link]
From: Dave O'Flynn (Aug 08 2013, at 09:33)
I've been on the implementation end for OpenID (as an IdP) and for OpenSocial (as a container developer).
The biggest issues we faced with both were:
1- Big providers don't care. Many of Google's OpenSocial gadgets never worked outside of iGoogle, and Google never gave a shit about fixing them.
2- Testing & Interop. A huge issue with OpenID. Lots of fun bugs and issues and IdPs or RPs that were not responsive to bug reports. How do you test? What happens when a major IdP releases a new version which breaks your app/site? If you're an iOS app, you're dead until you can get an update approved. Huge issue.
3- Migration. When an OpenID provider goes dark, you have to have the ability to migrate a user account from one provider to another. So you end up building more-complex identity-migration infrastructure than you would have if you just stuck with username+password.
4- Federation-Only? Unless you're willing to force people to use a federated login, you end up building all the normal username+password infrastructure, as well as the federated logins, leading to a seriously complex IdM infrastructure.
All of these are real-world issues I've seen. And they're not trivial - if you can't login, you don't have a business.
My personal opinion is that the provisioning aspects of federated login are by far the hardest part, and often skipped over by identity gurus (cf. SAML). Not so relevant to consumer-facing sites, but important for more enterprisey folk.
In the end, you end up with two choices:
A- Betting the business on Google/MS/FB/Apple/etc being a top-quality corporate citizen for the next decade or two.
B- Creating both federated and non-federated login paths, which really kills the usefulness of the whole thing.
If Google is serious about Federated Login, then Google should produce lang-specific libraries and do the integration work themselves for Device, Spring Security, etc, etc. That way it's drop-in for devs. But it'll take a long time to build back trust after OpenSocial and OpenID.
Does all of this make some kind of sense? Or am I just talking rubbish?
Good luck though - you're aiming at something big and important :-)
Cheers,
Dave.
[link]
From: Rich Salz (Aug 08 2013, at 09:51)
The problem is that it's not really federation right now, it's "delegate to us." Where us is a very small circle.
When I can fetch my Gmail using my FB account, then I will believe that federation is more than just another way to capture accounts.
[link]
From: Matěj Cepl (Aug 09 2013, at 03:02)
@Rich Salz:
“When words lose their meaning, people lose their freedom.” (apparently Confucius, but I know it from F.A.Hayek).
Federation which is not federated means that advertising agency wants to produce more lies. Which is their job, so no suprise there.
[link]
From: Eamonn Power (Aug 09 2013, at 08:02)
Like a similar comment before me, the key problem with a lot of authentication services is that they're more like composed services than federated services. If it was federation, I could login to my Google accounts with my Facebook ID and vice versa. This is generally not the case.
There are some local academic services in Ireland and Europe that are backed by federated identity systems. I can use my account from my local authority to access other institute systems and likewise we support access to some of our local system for those other institutes.
[link]
From: Matěj Cepl (Aug 09 2013, at 15:46)
@Eamonn Power:
BTW, this nicely ties with http://www.youtube.com/watch?v=azwP0eHML00 ... you can now login with your Google identity to any website supporting Mozilla Persona (or with any other identity which gets support ... either its own or Mozilla's). See https://developer.mozilla.org/docs/Mozilla/Persona/Implementing_a_Persona_IdP and http://ozten.com/psto/2012/11/01/self-hosting-my-persona-identity-with-hostedpersona-me/ for more.
[link]
From: Michael Clark (Aug 11 2013, at 11:05)
I have OpenId running on my web site. But many sites wont' let me choose which OpenID server to use. Or they think it can't possible be an OpenID server since they've never heard of it.
[link]