Single Sign On
Tom Scott
Public
Seen by 114
DIASPORA has a solid foundation, in many ways, but has lacked on adoption in a serious way. I think this may be due to a single root cause.
Our network does not work like other services such as Facebook or Twitter. Due to the centralization of those servers, it is trivial for external applications and services to make API calls to retrieve public data. You make one API call for authentication, then another to manipulate or retrieve data, and they're always in the same place, at the same domain, and return the same thing. Due to our design, DIASPORA can not work like this. At this time, we are imposing developers to implement a way to do this in their own apps. This is none of our apps are consistent, and IMO why app developers typically "give up" on us.
What we need is a single domain to relay some of this authentication and routing data from a central location to the pod that the user chooses. I want to be able to go to one place, enter in my username/password, and be redirected to my pod, already logged in. To keep true to our philosophy, this application should just relaying information back and forth without saving any authentication data or even tracking who visits the page. Basically it takes in a username/password, parses out the username for its pod address, and routes to the POST /users action on that pod. This logs the user in and redirects them to the pod's user dashboard, where they are free to use the DIASPORA network just as if they logged into their pod directly. Passwords would be typed in here, but never actually saved, instead they are encrypted and sent securely over the wire to the pod server (designated by the "@poddomain.com" part of the username string). As the SSO app would also be a Rails app, we'd expose the RESTful API so applications can use this server to log in as any user to any pod (provided the correct credentials are given).
Ideally, I'd like http://joindiaspora.com to not be a reference implementation, but where we store the SSO server. So to log in or to make RESTful API calls for authentication, one would simply have to visit joindiaspora.com. This would also encourage community pod adoption and perhaps question whether we need the main reference pod at all. It was always my understanding that the eventual goal of the project was to have the community sustain it, leaving the reference implementation would no longer necessary.
Is this even possible?
Tom Scott Thu 27 Dec 2012 4:12PM
@erwanguyader interesting. does it support a central location by which people can enter in their information? that's really what i was looking for here. the way we implement federated auth underneath that concept is somewhat irrelevant right now (when we begin making decisions on HOW this is to be implemented, then we can talk about whether we want OpenID or Persona or whatever).
Additionally, doesn't Persona feature password-less authentication, entirely handled on the local machine by the browser? That doesn't seem to fit in with our paradigm, as we do use (secure) passwords to authenticate users, and our authentication logic is handled on the server. Plus, from what it looks like Persona was developed for adding quick user identification and authentication to a site for things like comments or stuff that people shouldn't have to register an account with a password and all kinds of bullshit information for. It wasn't designed for systems like DIASPORA, where the primary motivation for using such a product is to have your information stored somewhere that you trust.
Guys, "decentralized" and "federated" are big words. And not just in amount of letters, they're becoming buzzwords thanks to a growing awareness of both privacy and the practices of large, centralized corporations by the general public. We need to have sharp eyes when looking at new technology, otherwise we might end up driving this project down so many rabbit holes that people will lose interest. It already happened once, I don't want to see it happen again.
Erwan Guyader Thu 27 Dec 2012 4:36PM
@tomscott What do you mean by central location to enter in information ? If you mean a web page on which people enter their email address and password, yes : login.persona.org
I haven't played with Persona yet but from what I understand, we wouldn't handle authentication on Diaspora anymore. Or we would do it by implementing the BrowserID protocol.
I think this page could give you information : https://developer.mozilla.org/en-US/docs/Persona/Why_Persona
I don't understand everything myself so you better read it yourself.
You can find everything about Persona here : https://developer.mozilla.org/en-US/docs/persona
Tom Scott Thu 27 Dec 2012 5:08PM
@erwanguyader from what I read, (https://developer.mozilla.org/en-US/docs/Persona/Identity_Provider_Overview) it looks like we can expose our user auth system as a Persona identity provider, enabling people to use their pod to sign in with other services.
I like this idea, but will it be sufficient for API clients? That's really what I wanted to learn from this discussion. It looks like BrowserID is a fine implementation of distributed identity for the browser, but is this useful on platforms that might not have access to the "whole web" like iOS or Android apps?
Erwan Guyader Thu 27 Dec 2012 11:46PM
@tomscott why wouldn't they have access to the whole web ? By the way, there is a native implementation of the Persona login for iOS and it works pretty well on Android.
Tom Scott Fri 28 Dec 2012 2:19PM
@erwanguyader they do, but sometimes in limited amounts. i know that I find apps to be "clunky" when they require an iOS UIWebView pane to connect to a service, and if we required all apps to connect to DIASPORA that way, all the time, I feel that would be a little annoying.
I searched (for "mozilla persona ios" and "mozilla persona android"), but couldn't find anything that looked remotely like a library. Do you see anything that we could just tell app developers to use, or perhaps wrap with our own library for authentication purposes? That would be the key ingredient. I'd be down with Persona if we could ensure access for all app (and any other client) developers on practically any platform.
Tom Scott Fri 28 Dec 2012 8:09PM
@flaburgan mind joining back into this discussion? persona is looking more and more like a viable option for this. how doable is creating a persona server that actually does require a password when logging into the pod?
Flaburgan Fri 28 Dec 2012 9:05PM
Hi ! Sorry, to no answer before. I'm not a native english, so it is hard for me to explain clearly here. I propose to you to go talk with the devs behind Persona on irc.mozilla.org #identity. They are really helpful. I will try to ask someone to subscribe here.
Btw, why do you want to require a password for log in using Persona ? I mean, of course, there will be a password, but you will not need to enter it each time you log in, and this is great, isn't it ?
Sean McArthur Fri 28 Dec 2012 10:11PM
I'm one of the engineers on Persona, and would gladly answer questions. What needs clarification?
Sean McArthur Fri 28 Dec 2012 10:21PM
Regarding Android/iOS: We don't have official libraries yet, but we're working on some. We realize that is extremely important.
That being said, Persona works fine in Android or iOS apps currently. You'd need to open a WebView, and then execute some JavaScript manually, and the dialog would give you an assertion, just like in a browser. Our libraries would hopefully do that part for you.
Erwan Guyader · Thu 27 Dec 2012 3:39PM
@tomscott Persona relies on identity providers. If each pod is turned into a provider, then Persona will contact the right provider when a user enters its credentials.