> On Feb 10, 2015, at 11:23 AM, Martin v. Löwis <mar...@v.loewis.de> wrote: > > Am 10.02.15 um 15:36 schrieb Donald Stufft: >> Honestly, I’d rather have less federated login not more. I wish the current >> OpenID support had never been added. >> > > Can you please elaborate on that position? Why is it useful to have > separate accounts on separate systems?
Sure. So the basic premise behind federated auth is that you can get a single set of credentials on all (or most) of your sites and eliminate the need to have a password for each site you visit. My opinion is basically influenced by a number of factors: 1. I feel like the goal of federated auth has failed in general and is unlikely to ever succeed. As a user of websites I have over 400 different entries in my password manager, even if 50% of them implement federated auth (which I feel like is a high number but that's not backed by math, just gut feeling) that's still over 200 entries I need to maintain in my password manager. In this case federated auth has not meaningfully reduced the burden of maintaining password for me since maintaining 200 isn't any easier than 400 and instead it just complicates my login flow 2. As a site operator I feel like authentication is a core part of the experience of using my site and by allowing federated auth on my site I'm giving up control over that user flow. A relevant example from PyPI is that a number of users signed up using MyOpenID which is no longer being maintained. This means that either PyPI has to tell those people "tough shit" or PyPI needs to figure out a mitigation tactic against that. Another example is that launchpad randomly starts failing for people, and it'll fail consistently for the same person until it just stops failing for them. I'm unable to actually reproduce this error so it's extremely hard for me to do anything else but shrug and tell them not to use it. 3. I feel like unless you solely rely on federated auth, then federated auth is always going to be a second class citizen for any particular website. For instance Travis CI uses federated auth via Github only, but that's the only thing they support for authentication so everything works well with that. On the other hand a number of sites support federated auth ontop of local accounts and federated auth is almost always worse in some ways, sometimes as simple as the username you get is kinda crappy (dstufft_<somehash>) sometimes some features don't work (or don't work very well) at all like on PyPI where we need to authenticate people outside of a web context so if we don't have usernames/passwords then we end up needing to require the user to register a secondary "api password" or API key. 4. I feel like none of the current solutions to federated auth are very good. OpenID relies on using an URL as your "personal identifier" which I feel like is a strange and foreign concept to most users. The way around this is often to just hardcode a list of sites, but then as a site operator you're implicitly recommending that users go sign up for one of those sites and use them on your site to login. This is creating an explicit relationship between your site and the other site, a relationship in which you often have no power (for instance, Google <-> PyPI, we're powerless to do anything about them deprecating OpenID other than just sucking it up and dealing with it). Persona did offer a way around this, but persona had other failings like relying on the domain that you happened to be using for your email to implement a persona IdP or otherwise falling back to an implicit relationship with the fallback provider, again one where you're more or less powerless to the operators of that service. Overall I think that the use of federated auth, as a site operator, is really only worth it over the loss of control in two scenarios: A. When your site is already entwined with another site and relying on them for authentication is simply increasing that. An example of this from above is Travis CI where they only work with things hosted on GitHub so also relying on GitHub for authentication isn't that big of a deal and actually makes things better since they can then integrate with GitHub's permissions to check if you have commit on a particular repository. B. When creating an account is likely to be enough of a burden to make people decide not to interact with your site. This category is basically completely comprised of sites that do not have long standing relationships with their users. The only real example I can think of this of the top of my head is sites with comments enabled like blogs, news sites, etc. The commentors are unlikely to have or want a long standing relationship with your site, they just want to make a quick one off comment and then possibly never come back. Sites like PyPI otherhand the cost of creating an account is small compared to the life time of majority of our user base's interaction with us. A key thing to me, as a site operator, is keeping as much control over the experience of my users as I can. Obviously I have to outsource some things because It's not reasonable for me to make my own hardware, write my own drivers, my own kernel, my own OS, my own webserver etc. A good example of a major outsourcing that I was involved in was moving things behind Fastly. However a key difference between that outsourcing and this outsourcing is that if things go sour with Fastly or we need to migrate away from them for one reason or another we can do that without end users needing to change much or anything. However if something like Google dropping OpenID supports happens then the users who relied on that are out of luck and our ability to shield them from the fallout of that is limited. At this point we already have it enabled, so unless someone comes up with a really good migration strategy I doubt we'll be able to get rid of it. However for the reasons above I'm pretty much against adding *additional* federated auth things and I think that we should treat it more of a legacy thing and downplay the fact we have support for it. Bitbucket has downplayed support for random OpenID as well, when you go to their login pages it shows a login form that looks like http://d.stufft.io/image/1O2l2g073h0h, which still lets you login with OpenID but it's muted and downplayed. In a slightly hypocritical view point, I actually think that at some point we should get something like id.python.org which is an IdP and switch all of the *.python.org sites to authenticate against that instead of keeping local user accounts. This would reduce the number of passwords that Python inflicts on people but it still keeps authentication within our (PSF/Python/whatever)'s control. This is more along the lines of implementing SSO using a federated auth technology than actual federated auth though. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
