原文地址:http://hinchcliffe.org/archive/2009/04/15/16745.aspx
Are
you creating a new Web site and developing a user registration system
that requires new visitors to sign-up and create a user ID and password?
Stop now and read this. There are now more effective approaches for
dealing with Web accounts which are more powerful and are better for you
and your users.
The concept of Web identity has recently
undergone significant evolution that all Web developers and architects,
both consumer and enterprise, should be readily familiar with today.
These new identity options, specifically OpenID, OAuth, and Facebook Connect, when individually used can:
- Make it easier, faster, and safer for users to establish their identity on your site.
- Enable businesses to have single sign-on to your applications.
- Turn your site into a platform for 3rd party applications which can access user data safely and securely.
- Can integrate your site or application into the social experience of the user and their connections.
This
post explores these three new ways to provide user identity that will
make your Web applications work substantially better and make your users
more secure and satisfied. There are also some important caveats and
issues to be aware of and which we'll also discuss.
Backstory
One
of the parts of the classic Web that's unfortunately still with us is
the trusty old user ID and password combination, one per Web site.
That's because the Internet itself has no intrinsic identity system
built-in; anonymous access is the default and anything more
sophisticated has to be cobbled together one-off for each site. This
means most Web sites today implement user identity uniquely with
different sign-up processes, user ID requirements (sometimes you get to
pick, sometimes you have to use your e-mail address, and very often your
favorite ID is already chosen, etc.) Then there are varying password
length requirements if you are lucky, variable recovery processes if the
password is lost, and so on. This is the challenge of an open,
decentralized system (the Web) that has very little top-down design: How
to provide users control and consistency in an online world where there
are very few widely accepted user-centric open standards.
Interestingly,
this is the one of the rare instances where enterprises got it right
long before the Web and is now a relatively well-solved problem -- at
least inside the firewall -- with something known as single sign-on. Often referred to as SSO and embodied by technologies such as Kerberos, smart cards like RSA's SecurID, and Windows Integrated Authentication,
single-sign on ensures that users have just one single, consistent
identity and sign-in credentials. Single sign-on works then seamlessly
to enable them access to the various applications that they use on the
network. There is only one user ID and password to remember and it can
be reset, administered, or even shutdown centrally whenever required.
However,
these enterprise approaches -- as good as they have become -- are
generally unsuitable for the Web identity for several reasons; they are
either involve proprietary approaches (which is anathema to gaining the
support from the Web community which thrives on open standards), require
special hardware, or are too hard to implement consistently across the
hundreds of different languages, frameworks, and platforms that make up
Internet the today. In fact, anything that isn't aligned closely to the
way the Web works, recognizes the browser as the first-order Web client,
and offers a lightweight, open approach that's easy to implement from
most toolkits just won't succeed.
Note I say "easy to implement"
is a requirement for Web identity systems and I should note that making
user identity truly secure is one of the harder problems in software.
This can mean that OpenID and OAuth require a fair amount of work to
implement successfully. The good news: All three new identity approaches
presented here are now fairly easy to use right out of the box since
much of the hard work has been done to create libraries for the most
common programming languages and environments. I will observe that it's
still up to you, the designer of the Web application, to ensure these
libraries are doing the right thing by your users. This is yet another
reason why Web identity is still so often reimplemented over and over
again; lack of trust of 3rd party code and not-invented here
are still two powerful forces in software development. However, the
value proposition has grown to the extent that these do-it-all-yourself
positions are growing increasingly untenable.
That's not to say
considerable care shouldn't be used. In general, the more important the
user data your application handles, the more auditing and regular code
reviews you should conduct of your security and Web identity libraries.
The identity options: OpenID, OAuth, and Facebook Connect
Each
of the identity options presented here does something slightly
different in terms of providing users with either their choice of login
and Web identity or safe access to their data from elsewhere on the Web.
As such, you will likely be faced not with choosing one of these three identity options but actually all three of them to give your users the options they what and will increasingly expect. I've highlighted in the past the number of core competencies
that modern Web developers and architects have to master these days,
and it's a tall order. These options add to that burden but as you'll
see, provide considerable value in return.
OpenID
The best and most authoritative explanation of OpenID can be found here at OpenID Explained.
It's quite simple: Let your users use the identity provider of their
choice to login to your application instead of filling out an online
form and capturing the information in a private, local account that
users are not likely to trust nor long remember. Chances are nearly 100%
that a user already has a valid OpenID from the many popular services that already allow their IDs to be used this way today. OpenID use is also growing: Recent reports
show that sites offering OpenID logins are currently reporting that
10-15% of users will login this way and the average is climbing. Venture
Beat also had a decidedly bullish outlook on OpenID today.
Many
site have their business model and valuations wrapped around the number
of registered users that they maintain. OpenID does NOT make this model
go away, it merely provides an easier way to begin a relationship with
new users. It even makes it easier for the user to interact with a new
site. The full set of benefits for offering support for OpenID is:
- Faster and easier sign-up.
Users get the choice of ID they prefer to use and can also choose how
much information you get to see about them. You can still ask any
necessary registration questions after they sign-up with their OpenID.
Note also that field experiments have shown that the simplest possible registration process is 3 times
more effective at eliciting sign-ups. OpenID naturally takes advantage
of this fact and is the perfect complement to the highly effective lazy registration pattern.
And don't forget that you still get to add the user to your local
account database with all the information you care about, just in the
context of their OpenID, meaning that you don't get to know their
password or any other information they don't want to give you. - Better sign-in process and lifecycle.
Users only need to remember one user ID and password and so will always
have an easier time logging in. It also places the burden of password
maintenance and account support (at least some of it) on the 3rd party
OpenID provider. And since the OpenID standard makes sure that passwords
are used in a secure way and never passed along directly to sites that
offer OpenID logins, users feel safer continuing to use new sites. As
I've explored in the past, OpenID also potentially allows enterprises to extend their single sign-on experience out across the Web to SaaS applications that support OpenID. - Consistent Web identity. There have been many discussions recently about namespaces as the new lock-in, particularly today's post from Chris Messina,
and OpenID allows users take advantage of this to establish their own
namespace consistently across multiple Web sites and indeed, the entire
Web. When someone sees a given OpenID on a site, they'll know it's the
exact same user they see on another site. Giving users the ability to
unambiguously identify themselves authoritatively on your site will be
seen as an increasingly important requirement of today's social Web.
To actually support OpenID, you'll need to implement the current specification or use one of the many available OpenID libraries that already does it for you. Support exists for all the common languages: C#, Java, Perl, PHP, Ruby, Python, and even Haskell. The bottom line, you'll be learning about digital signatures such as HMAC-SHA1 and extensible resource identifiers, or XRIs.
It
should also be noted that the getting the user experience of OpenID
right is essential for being successfully with it. Because most visitors
will still be unfamiliar with it, a lot has been learned about how to
offer the sign-up and sign-in experience in a way that is accessible and
understandable. Early OpenID adopters often made the process too
complicated or inexplicable to the user. A lot has been learned about
how to do this correctly to enable the double digit usage rates we're
seeing today on sites that are successful with OpenID. Probably the best
presentation about effective OpenID user experiences is Brian Ellin's deck from this year's OpenID UX Summit, I encourage you to study it.
OAuth
Using
a site through its user experience is now only one way in which the Web
will interact with your service. If you're only offering a visual user
experience and don't currently have an application programming
interface, or API, you're behind the times. Open APIs
are one of the most powerful new models for delivering services on the
Web and they enable 3rd parties to integrate with and build on top of
your product, creating all new services and mashups. This leverages something I refer to as Jakob's Law,
which says that most of your traffic will ultimately be driven by
external activities on other sites. Thus, more usage will often come in
through an API than through the user interface. For example, Twitter
famously has 10 times more usage through its API than through its Web
experience, which I recently reconfirmed is still the case with Twitter's Alex Payne at Web 2.0 Expo earlier this month. It's also no accident that Twitter recently added support for OAuth.
However,
the challenge with APIs is the same as with user experiences: How to
let users access their data remotely in a safe way without having to
give the 3rd party application their user ID and password for your site?
Users might even feel comfortable giving their credentials for a
Twitter application like Twitterific,
but they certainly aren't going to do that for critical applications
like e-mail, banking, or e-commerce. Enter OAuth, a method for allowing
3rd party applications to gain access to user data with their
permission, but without having to give the credentials to that
application. In other words, users can "authorize" 3rd party
applications to access their data in your site, without giving that 3rd
party application the user ID and credentials.
The benefits of securing your API with OAuth include:
- Safe, secure 3rd party data access.
Users will be able to give permission for specific apps to access their
data on your site without having to share their user ID and password
with the 3rd party. - Declarative control over 3rd party access.
Users can also block the access of 3rd parties they previously
authorized without having to have access to the 3rd party application.
This gives them declarative control over who accesses their data and
makes them more likely to use such applications. - Greater use of 3rd party applications drives local use.
For many applications, handing out user IDs and password to 3rd parties
is unacceptable to users. They will only use the sites they trust.
Since the APIs often become the dominant channel through which usage
occurs, meaning that 3rd party sites can often represent the bulk of
interaction if appropriate security controls are in place and users feel
safe, OAuth can drive increases in usage and traffic.
You can find the OAuth specification here but most will opt to use one of the many pre-built libraries
that is already available and which greatly simplify implementation.
The language options are much the same as with OpenID which is good
since OAuth is seeing broader and broader adoption as its benefits
become clear and it gains critical mass.
Reconciling OpenID and OAuth
Now,
those paying close attention to this discussion might notice that
OpenID and OAuth seem in direct opposition. OpenID allows users to
employ remote 3rd party logins and OAuth tries hard to make the local ID
safely usable externally, at least when it comes to access through the
API. In reality, OpenID and OAuth are an excellent combined strategy and
plenty of work is underway to make it possible to use OAuth with
OpenID. Sites that support this combination will use the user's
preferred login for both the user experience (UX) of the site as well as
for the API, creating a seamless, consistent experience. The Step 2 project
has begun to "combine the OpenID authentication and the OAuth
authorization protocols" and has involvement with many of the major
players in the space including Joe Smarr of Plaxo and David Recordon of
Six Apart.
OpenID and OAuth represent major, scalable Web
identity authentication and authorization systems that work with both a
user experience as increasingly popular API access methods. They are
both open standards and have the backing of many major players,
particularly OpenID which has the backing (though only partial
implementation) from Yahoo!, Microsoft, IBM, Google, Facebook, and other
influential organizations.
Facebook Connect
Open Web advocates are probably wondering why I've included the proprietary Facebook Connect
in this discussion of Web identity. That's because there is as of yet
no major social identity system that is open and has broad support.
Consequently, I will warn you that using Facebook identity is something
that should be done carefully with eyes wide open for the lock-in issues
and dependencies that can result. However, the value proposition is
considerable. For example, Facebook claims that for many sites "2 out of 3 new registrations come via Facebook Connect, and those users have about 50% more engagement on sites". This alone will be worth it for a great many services, and certainly thousands of services have agreed.
By social identity I'm referring to not just a user's individual identity but also their social graph,
or list of connections they've established online, as well as the
communication that takes place between those contacts, typically an
activity stream.
Social identity is fast becoming essential
context for for online applications; it's not just enough to have you as
a registered user since today's Web applications also need to know who
your connections are in order to provide the services they offer for
communication, collaboration, etc. Social identity systems allow you to
login and then be able to refer to and access your social connections
and communicate with them. This is far preferable to the old-school
equivalent: Importing your contact lists and then inviting all of them
to the new application you're using. The days when that was acceptable
are over, if they ever were. Now you can just use your social identity
and they can see what you're doing in their activity stream and decide
whether or not to respond or participate.
For example, I use the video sharing site Vimeo
quite often but many of my friends don't and don't even have an account
there. But they can see what I'm doing on Vimeo with my Facebook
Connect link that shows my videos in their Facebook activity streams
when I post them. They can then decide if they want to view the video or
otherwise interact with Vimeo.
Facebook Connect itself is a
simple set of JavaScript libraries and XML markup that allows you to
enable users to connect to their Facebook accounts from within your Web
application. The capabilities and advantages of Facebook Connect are:
- Single-click login. Users can log in with their Facebook identity and allow your site to access their Facebook profile.
- More engagement. Use a user's personal interests to provide more relevant information and offer customized content from friends.
- New distribution models.
Users can share content and actions taken on your site with contacts
back on Facebook through the activity stream and other social
communication channels on Facebook. - Direct access to Facebook. Use the APIs that have allowed more than 700,000 developers to build tens of thousands of applications.
Getting started with Facebook Connect is relatively easy and the startup guide is straightforward.
The integration is very platform-agnostic and requires little
implementation for basic capabilities though it does use proprietary
JavaScript libraries and XML markup. To get the most out of Facebook
Connect will require deeper integration however, and this will create
more dependencies on how Facebook manages social data and activity
information. Fortunately, most good architects will be able to create a
straightforward separation of concerns and one that will allow other
social identity systems to be plugged in as they emerge, especially on
the open side, such as Plaxo's Open Social Graph.
While
many organizations remain uncomfortable delegating any aspect of user
identity to external services, the reality is that online services are
invariable stronger, more robust, and more attractive to users when they
do. The effort is higher however, and there are more dependencies to
manage but Web identity has definitively entered a near era. Proactive
companies that take advantage of what is possible today will be poised
to enjoy additional growth, higher user retention, and better customer
relationships.
作者：蒋金楠
微信公众账号：大内老A
微博：www.weibo.com/artech
如果你想及时得到个人撰写文章以及著作的消息推送，或者想看看个人推荐的技术资料，可以扫描左边二维码（或者长按识别二维码）关注个人公众号（原来公众帐号蒋金楠的自媒体将会停用）。
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。