October 4, 2006
This article was contributed by Jake Edge.
The OpenID project is an effort to
produce a decentralized, open, user-centric identity management framework.
The main benefit for users will be a 'single sign on' to websites that
support it. The project provides open source libraries for both
websites requiring authentication (relying parties) and for the
servers that provide the authentication (identity providers, IdPs).
One of the main goals is to allow anyone to run a server that authenticates
their own or others' identities and avoid the centralized model of other
identity frameworks.
At its core, OpenID allows a user to associate a URL with his or her identity;
a server can then authenticate that the user is the owner of that URL.
Giving users control of their own identity makes OpenID a user-centric
identity management system. To use OpenID authentication, the username
is the URL and the password is stored on the identity provider.
Thus, the same password is used to authenticate multiple accounts on
various websites.
There are different ways to use OpenID, depending on what the user's
requirements and capabilities are. In the simplest case, one can sign up
for a free account at a provider like
MyOpenID and it will generate a URL
for you to use (the author's test account was jake.edge.myopenid.com).
After that, you can submit that URL at any OpenID enabled website and
authenticate it. If you have not visited the site before, you
will be redirected to MyOpenID to enable that site to authenticate you.
You may also need to login to MyOpenID if you have not established a
session there recently. Once you have enabled authentication, you are redirected
back to the original site and MyOpenID will have authenticated you. If you have
a valid MyOpenID session and have previously enabled the site you are
visiting, you can be authenticated behind the scenes when you provide
your URL and will be able to log in without providing a password.
Another way to use a service like MyOpenID is by using a URL under your
control as your identity. By putting some HTML into the HEAD section of
the index document served from that URL, you can delegate the authentication
to another server and gain the benefits of
using your own URL without running your own OpenID server. If you do that,
the URL for OpenID logins becomes the URL under your control. Over time,
you could change the server that you delegate to while still retaining the
identity associated with your URL. In addition, various OpenID server
implementations exist for those who wish to fully control their identity
and can run their own server.
OpenID implements the authentication by using (but not requiring) strong
encryption on the messages that are exchanged between relying parties
and identity providers (IdPs). When a user enters a URL into
an OpenID login, the relying party makes a GET request to the URL and
expects to find some extra OpenID specific markup in the HEAD section. It
uses this markup to find the IdP and can negotiate an association between the
relying party and IdP, but does not have to. The association is an
agreement on cryptographic protocols to use to sign the requests and
responses. A relying party can then cache that information to use when
contacting that IdP for any other user that might share the server.
After that, the relying party redirects the user to the IdP which allows any
IdP specific cookies to be delivered. The IdP may decide to require the
user to authenticate with it, but that is outside of the scope of the OpenID
specification. As described above, the IdP may also require the user
to make a decision about whether to allow the relying party to authenticate
them. Once that is complete, the IdP returns the user to the relying party
site with an assertion about whether the authentication succeeded or failed.
The most recent OpenID
specification
adds some additional capabilities. A nonce (a unique identifier)
value was added as an option to the success response to thwart replay attacks.
Also, support for Yadis discovery was added.
Yadis allows relying parties to determine what authentication protocol
to use so that sites can transparently support other protocols such as
LID.
From a security standpoint, there are a few different attack vectors that
are described in the specification. Eavesdropping and man-in-the-middle
attacks can be circumvented by using HTTPS (SSL). Unless the IdP is
compromised, the identity itself is secure, though it could be spoofed
on a particular site using those vectors.
OpenID simply makes the connection between a URL and an identity,
it asserts that the two are associated, it does not provide any trust
information
about the identity. Users of OpenID will still have to prove they are
not programs at registration time because nothing in the protocol prevents
programs from having identities. It is a starting point, as any kind of
trust system must be based on an authenticated identity. A trust layer
that uses OpenID identities could provide protection against blog spam
and the like. Since OpenID identities can be anonymous, this will
allow for anonymous, but authenticated, users; one can verify that the
identity wrote a particular message without making a connection to the
real life person behind it.
There seems to be a growing number of
sites
that support OpenID; there is even a
bounty for adding support
to open source programs. Overall, it seems that OpenID provides a fairly
painless route for digital identity management for both users and websites.
It is probably worth a look for anyone that might be interested in such a
thing.
Comments (18 posted)
