?

Log in

No account? Create an account
Previous Entry Share Next Entry
Fun with Identity
device
jducoeur
[Technical article ahead, although more about architecture and concepts than details.]

Today's project was starting to figure out the login process for Querki. It's been educational.

One of the early decisions was that Querki isn't going to have its own logins, at least not by preference. (The option *might* exist, but I'm still not sure.) Frankly, managing passwords and the like is a hassle, at least to do it properly: you have to be utterly scrupulous about the details, and there are a lot of ways to screw up. And really, there's no good reason to do so any more -- the Internet is chock-full of "identity providers" that *want* to be in that business, and there are well-established protocols for Querki to, eg, ask Facebook "Is this the person he claims to be?". So it's pretty straightforward for me to just delegate that problem elsewhere.

In theory.


There are two things I'm cranky about at the moment. The simpler is that it looks like supporting LiveJournal (and DreamWidth) identities may be more trouble than it's worth.

The thing is, LiveJournal pretty much invented the modern concept of distributed identity, way back when, with a standard called OpenID. Basically, I can just go to a site that uses OpenID, give my identity as "jducoeur.livejournal.com", and there's this dance between that site and LJ to establish that I am who I say. It was kind of a clever hack, but it basically worked, and has been through a couple of versions now.

The problem is, OpenID is very limited. It establishes *who* you are, but nothing else. Modern social networks generally want more power than that -- they want the "relying" site to be able to ask for permission to see your email address, or post to your wall, or see your friend list. So a fancier protocol was invented, called OAuth. That's also evolved a bit, and OAuth 2.0 is becoming one of those central standards. It's supported by a lot of the important players -- Facebook, Google, Twitter, and so on. But so far, I can't find any evidence that it's supported by LiveJournal. (I would be happy to be proven incorrect here. I've found suggestions that folks were working on OAuth for LJ, but no indication that that's actually become live.) (Edit: It looks like DreamWidth is at least working on it. No serious sign that LJ is.)

Of course, I don't want to write all the code for this stuff myself. And the heart of the problem is that about half of the libraries to do this sort of distributed login *only* support OAuth nowadays. That's not crazy -- in many ways, it's the more sensible approach -- but I have to decide how much I care. I would really *like* to support LJ and DW as identity providers, since it is where many of my friends focus. But the sad truth is that the vast majority of likely users care much more about Facebook and Google support. So I may have to make some choices there; if the best libraries don't support OpenID, I may have to give up LJ as an identity provider.


The deeper thing that's making me twitchy is the change in attitude about identity. Most everybody agrees that distributed identity is a good thing, but there are two very different attitudes, which I think of as the "whitelist" and "blacklist" approaches. These can be distinguished by a simple question: are users allowed to simply say, "This is my identity", or are they limited to a few pre-defined options?

Far as I can tell, the latter viewpoint is *heavily* winning now. Most of the tools and libraries I'm looking at now fundamentally assume that the relying site (that is, me) predefines which identity providers it is willing to talk to. The deck is *heavily* stacked in favor of the big providers like Facebook and Google: you can add other sites (so long as they implement OAuth), but it requires additional configuration, and sometimes additional code, to do so.

This saddens me. Frankly, I think it's a betrayal of the spirit of the Internet, and pretty dangerous from a societal viewpoint. It's another step towards allowing a few big companies to "own" our identities, which seems like a pretty bad idea on its face.

(The OpenID vs. OAuth thing comes into play here a bit. OpenID, by design, allows for any number of arbitrary identity providers. I suspect it's not accidental that Facebook and Google are quietly working to squash it. Today's big irony was the discovery that AccountChooser -- the big push by the OpenID Foundation for a standard -- doesn't support OpenID.)

There are certainly arguments in favor of the whitelist model (only allowing a few identity providers to be considered valid). In particular, it avoids having to deal with potentially fraudulent identity providers that then need to be blacklisted. And I suspect I'll be pushed in that direction, simply because I don't have time to fight this particular crusade. But I am reminded of why the nymwars fired my blood so much...
Tags:

  • 1
OAuth and OpenID aren't really designed to solve the same problem, are they?

OpenID is designed to solve the problem of identity, especially in a browser: "I am the person represented by the URL $foo".

OAuth lets you authenticate with a service -- so, it allows you to say "I have obtained credentials from service $bar", and is usually directed at talking *back* to that service, isn't it? I mean, I think you can use it as identity, but that's not the core point of OAuth, in my experience -- the primary use case I've always thought of for OAuth is "I want to give a mobile app credentials to act as me, without giving that app my password directly." You can do the same thing, where 'mobile app' is replaced by 'third party website', I just didn't realize that was really the way things were going.

I also thought that http://openid.net/specs/openid-simple-registration-extension-1_0.html was the answer to the "Let me get the other basic information about the user" -- unfortunately, it seems, based on https://willnorris.com/openid-support that LJ doesn't support it, despite being one of the original proof of concept use cases. Ah well.

Ah well. Identity sucks.

Yaas. And yes, it's true that OpenID and OAuth are trying to do somewhat different things, which is why the results of yesterday's surf surprised me. But it looks like (based on a whopping few hours of research) most folks are moving towards thinking of authentication as a strict subset of authorization -- that since you have to have authentication before you can authorize anything, you can just think of it as the degenerate first step.

From a conceptual POV that's dead-wrong -- indeed, authentication and authorization don't necessarily have anything much to do with each other, and I'd argue that they *shouldn't* have much to do with each other. Linking the two ideas like that limits both of them, in ways that probably aren't good for users. The healthiest ecology would be one with highly distributed functionality in all directions, letting users pick the best system for each function.

But it is very much in the interest of the walled-garden providers to conflate the two concepts, so as to help lock their users into a single all-encompassing space that defines both who they are and what they can do. Facebook and Google are pushing things towards a neat oligopoly with just a few central providers of identity, news feeds, access control and suchlike.

All horribly broken, but there's not much I can do about it yet. I suppose this is yet another argument for pushing Querki forward and making it succeed -- I'm in a much better position to conduct a crusade to fix the Internet if I've got a successful company with at least a few million users first...

I don't see how it binds authentication to authorization. It moves the responsibility for authorization to the resource. So each querki app would have to maintain a database of identity to role mappings. Once the application receives an authenticated identity, it looks up the authorization.

A SAML token can carry role information as well as identity, which has the option of moving the authorization responsibility back to the identity provider.

Not Querki's authorization -- the authorization of the social-network functionality such as maintaining friend list (access control), maintain a news feed, and so on. That is, the major players have set things up so that you can only use their applications (authorization) if your identity is maintained with them (authentication).

That's the part I consider unhealthy from an ecological POV: it biases the 'net towards a vertically-integrated approach that looks like a generally bad idea to me. I thought walled gardens were a bad idea back in the days of AOL and Prodigy, and I still do...

oh, hmmm. So the model is querki behaves as a g+(for the sake of argument) client. The oath token you receive doesn't just identify the g+ identity to querki, it grants access to my g+ resources to querki, almost as a side effect. That could give me hives.

Edited at 2013-03-13 05:30 pm (UTC)

Just so. It's coarse-grained in a way that makes me twitch, but it's the model that the big players require, so I kind of have to play along. I believe it *can* be somewhat finer-grained -- but almost never is in practice.

As it is, I suspect that *I* am going to have to provide finer-grained permissions control on my side, because what I've seen of the user experience from the big players is kind of weak. That is, while I certainly want my users to give Querki permission to post updates to their wall and such, I'd rather that be a conscious decision, not the usual "yeah, whatever". But having me doing it on the "client" side of the connection is pretty daft from a security POV...

I see a world of hurt coming - there have been rumblings already wrt rogue applications and twitter.

Even using the model the way it is intended isn't exactly perfect. I implemented oauth authentication to Ravelry (not ready to ship, but I have it working so I grok it). When the sockcalc user wants to access their Ravelry account, sockcalc pops a webview to Ravelry's authentication page. The user types in their credentials, rather than giving them directly to sockcalc to misuse) and sockcalc picks up a token it can sign ravelry API calls with.

There's nothing on earth preventing me as a rogue dev from stealing those login creds - it's still done through my application. The password is likely to have a longer life than the oauth token (although twitter managed to screw this one up with non-expiring tokens) and I can use it to attempt to move laterally in the user's identity space if they are foolish enough to re-use passwords.

sigh.

Yeah. And to be fair, this is one of the motivations behind AccountChooser, the least-flexible of my options (and the one being pushed behind-the-scenes by Google). It has a host of problems of its own, but does at least have the advantage that it puts authentication into a neutral window (from "accountchooser.com"), not controlled by the relying site; I suspect that makes it at least a *bit* less susceptible to this sort of easy interception...

I didn't think OAuth was really intended to be an identity, it is more about delegating access to resources you own (permission to post to my twitter, permission to access my Ravelry account).

SAML is more about federated identity, the model suits better to granting access to a resource you own based on identity and authorization established by a third party.

I didn't think OAuth was really intended to be an identity, it is more about delegating access to resources you own (permission to post to my twitter, permission to access my Ravelry account).

I concur, and that's why this all surprised me. But Facebook and Google *want* identity and authorization to be bound at the hip, so I think they've nudged things in a direction of thinking about authentication as a subset of authorization. (See upthread for additional rant.) At least, it appears that the new generation of tools is treating OAuth that way...

I was suddenly put in mind of the SCA College of Arms's notion that every person registered must have a unique name....

Edited at 2013-03-13 05:26 pm (UTC)

But so far, I can't find any evidence that [OAuth] is supported by LiveJournal. (I would be happy to be proven incorrect here. I've found suggestions that folks were working on OAuth for LJ, but no indication that that's actually become live.) (Edit: It looks like DreamWidth is at least working on it. No serious sign that LJ is.)

Ah. That might be a reason behind the lack of ifttt.com modules specifically for DW / LJ. (Rather than the generic "Feed" module.)


Yeah, makes sense. In general, LJ's APIs are -- well, let's just say "idiosyncratic". (And poorly documented.) The DW folks have made things somewhat better, but it's a creaky old codebase, and I suspect that integrating with it isn't simple...

IdM/IAM is a messy, messy topic. In some ways, simply properly salting and hashing passwords and storing those opaque blobs reliably is easier. It's why so many people are still doing it themselves, or giving up and just defaulting to relying on the big players. As someone who uses his own domain as an OpenId provider, I too wish there were better support for it. Most services don't need the full breadth of OAuth, and I like not having to give every service a username and password, so long as they can reliably keep the association between my OpenId and my service account.

I've been looking at SAML and other in-organization tools to handle some of this passing of info between tools, and just went to a presentation on http://ciferproject.org/ and the real takeaway is that this is still far too messy and far too difficult, and that's -inside- of an organization where you have additional units of knowledge and access to leverage (Presumably, you know who is in your organization and what tools they should have) Doing it out on the web, with a soft 'open to all' approach is even messier.

As someone who uses his own domain as an OpenId provider, I too wish there were better support for it. Most services don't need the full breadth of OAuth, and I like not having to give every service a username and password, so long as they can reliably keep the association between my OpenId and my service account.

Yaas. Aaron and I were chatting the other day about whether it would be possible to write a neutral third-party service that transformed OAuth requests into simpler OpenID ones, so that my OAuth client could at least perform authentication against OpenID servers. (And simply declare that no other services were possible.)

The idea isn't crazy in principle, although I have no idea whether it would be possible in practice to glue the two protocols together in an adequately secure way. Might be something for me to look into sometime...

I'm not sure if G+ is continuing to try to claim "You must use your real name", but Facebook *certainly* is. Right there in and of itself that's enough to keep me entirely off Querki even without the next issue I'm going to bring up-- I don't use my real name on the internet for anything but Facebook and professional or commercial purposes, and no matter how useful a site will be, if it demands my real name for anything other than making a purchase or applying for a job, I won't use it. (And even in those cases, there are a lot of specific circumstances that will cause me to not make that purchase or not apply for that job-- I do not trust the internet.) Therefore if Querki wants me to use Facebook as an authentication mechanism, I won't use Querki because my real name would then be associated with whatever I do on Querki. In all honesty, I prefer to have the option of having a unique username everywhere-- at this point I have four or five unique usernames with more or less separated identities. (And Querki is the sort of site that I would usually have a whole new unique identity on.)

And then there's the *other* problem... in my experience, if I use Facebook to log in to something, I don't get the option of choosing what it posts to my wall, and even if I do get that option it can change at any time without warning as Facebook's privacy controls and policy change-- honestly, I've never been certain what's the original application posting stuff to my wall and what's Facebook deciding that everyone needs to hear about everything I do. I don't even play games on Facebook as a result of this. Something like Querki where you're supposed to be using it to organize your life, and I'd get *very* paranoid about the privacy controls involved.

Well, keep in mind that, while Facebook *claims* to require real names, they've never actually done much about it. Indeed, I'd guess the majority of my friends on Facebook have never used their real names there -- folks just ignore that policy routinely, and I don't know anybody offhand who has ever been hassled for it. (Whereas Google has made an annoyingly concerted effort to actually *enforce* the real name requirement, which was where they got into trouble and pissed folks off.)

I'm still pondering whether Querki will have its own username/password system. I sympathize with your viewpoint, but keep in mind that it is a *lot* of work to do well -- possibly more than building the site so far itself. It's very easy to do this sort of thing badly (and many sites do), but actually managing authentication properly is an art unto itself. That becomes yet a bigger issue with the trend towards OAuth -- it would be plausible for me to just run my own OpenID installation, based on an open-source implementation, for folks who demand one, but I don't know an out-of-the-box OAuth implementation offhand.

in my experience, if I use Facebook to log in to something, I don't get the option of choosing what it posts to my wall

Actually, well-designed and responsible sites usually do make that optional -- unfortunately, not many sites are responsible about this sort of thing. (The only one I use that seems to handle it more or less correctly is MyFitnessPal.)

By and large, that sort of thing is almost always the application's fault. After all, *Facebook* shouldn't know about any of that if you don't want it made public, so they surely couldn't just post it; it's the app's fault for putting it there. Like I said, irresponsibility is pretty common with personal information.

Anyway, the paranoia is entirely understood. Only thing I can say there is that I am probably a lot more paranoid than you are -- after all, I'm going to be using Querki more heavily than anybody, for a lot of stuff that isn't public -- and know the issues well. So I have a vested interest in not screwing it up...

  • 1