Slashdot Mirror
OpenID - Open Source Single-SignOn
Nurgled writes "Danga Interactive, who created LiveJournal and memcached, is working on a new decentralized single-signon system called OpenID. Similar in principle to Six Apart's TypeKey or MSN Passport, OpenID will allow you to assert a single identity to any OpenID-supporting site. The difference here is that there is no central authenticating server: anyone can run one, and Danga's reference implementations will be open-source. The site you are authenticating with never sees your username or password, just a one-time token. You can read the initial announcement on LiveJournal, though some details have changed since that post, so be sure to read the information on the official site."
Does it mean I have release my password per GPL and anyone is allowed to modify and distribute it for free?
If you ran one, you'd have only your authentication information stored on your server. Then, to authenticate to a remote server, you'd point that server to your server. The remote server would ask your server who you are, and then authenticate you (log you in). The biggest thing is that the remote server has to trust that what your server tells it is correct.
This may have a place in the blog world, where you're mainly looking for an easy way to keep your user profile the same across many blogs, but certainly not anywhere where you'd have sensitive data.
Another point, this is supposed to be authentication and not authorization. But actually, this isn't really authentication either... The difference between the two is really the question the server is asking. In authentication, the question is "are you who you say you are?". In authorization the question is "do I have the rights to perform a task?". With OpenID, the question is "who are you?". There is no verification to see if you are who you say you are (from the remote server's perspective, since there is no trust between servers), so you aren't actually authenticated.
It would be up to your server to determine what rights an open-id authenticated user would have.
"If we knew what we were doing, it wouldn't be called research." - Einstein
You could still use cookies based on the sign on. Instead of getting the sign-on data from the user typing it, you would be getting it from the token and perhaps looking it up on the backend. It makes it easier for the user, and is about the same amount of programming for you. You can still set and delete cookies accordingly.
Decentralized servers are no less secure than if you had a database table of your user authentication information for your application. With SSO, you actually don't need to know the password since it has already been handled. All you need back is the user ID and that they have been authenticated. If you choose to set one of these servers up, it isn't like people are going to start using your server to store their Online Banking information. They will be using your server only to access sites that you run.
On the flip side, if you choose to latch onto someone else's server for authentication, all you will be doing is specifying that you allow anyone authenticated by that server to access your site. You wouldn't even have as much knowledge of those users as you would if you ran your own security.
For the most part SSO is only really usefull within a small environment. Very rarely do I see a need to allow people to access more than one application with the same sign on. Something like passport is nice for the general user, but why would I want the overhead of something like that for my own applications? I'd rather have more control over things. That sort of makes this new product interesting to me, but on the other hand, most of my applications have distinct user sets anyway.
/. ++