Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼

Web Development

OpenID Single Sign-On

Jeremy is a software engineer at PatientsLikeMe (www.patientslikeme.com), a social network and health-management tool. He can be contacted at [email protected]

Many software applications—including websites—offer features that are only available to users who first log-in to the system. In a typical application, user identity is confirmed ("authenticated") upon entering the username and password for the account. This approach is straightforward and works, but there are drawbacks. For instance, most apps reinvent the wheel when it comes to authentication, and many do-it-yourself implementations are easily exploited because developers may not have expertise in security. Users are usually required to remember a username/password for every application they use, which can be problematic.

OpenID (www.openid.net) is an open standard that defines a way that web-based applications ("consumers") can authenticate users by delegating the responsibility of authentication to identity providers. With OpenID, users have a single identity that can be used on any OpenID-enabled application, and they only need to remember one password.

In this article, I describe the OpenID authentication system and show how a web application built with Ruby on Rails can use OpenID to authenticate its users.

How OpenID Works

OpenID relies on the HTTP protocol to exchange messages between "consumers" and "identity providers." Consider a user named Bob, whose identity provider is myOpenID (www.myopenid.com). Bob uses the Drupal content-management system that happens to be an OpenID consumer. Here's the general workflow when Bob logs into his Drupal account through OpenID:

  1. Bob visits his Drupal-driven website.
  2. Bob enters his OpenID identity URI, "bobs-id.myopenid.com," in the login form and clicks a Submit button. That's his OpenID identity URI, which looks like a website address, but identifies Bob and his identity provider.
  3. Bob's web browser is redirected to a web page served by myOpenID, where he is prompted for his password.
  4. Bob enters his OpenID password and clicks a Submit button.
  5. myOpenID confirms Bob's password, and his web browser is redirected to Drupal with some information about Bob.

Bob entered his password only on the identity provider website, and never on the consumer website. The user's password is not shared with the consumer and only needs to be submitted once by users to the identity provider, preferably over a secure connection.


OpenID provides several benefits to users and developers. Users only need to remember one username (their identity URI) and password to access multiple applications. With a simple cookie and Remember Me checkbox, an OpenID identity provider can act as a convenient Single Sign-On (SSO) solution for someone who uses multiple OpenID consumers.

OpenID identity providers are responsible for the authentication of users, giving web developers one less thing to understand, implement, and maintain, and letting them focus on core business. Supporting OpenID removes a barrier to entry for many potential users who balk at yet another website asking them to sign up.

It's not uncommon for web apps to offer OpenID support as an alternative to traditional authentication methods, but letting experts handle password security reduces the risk of accounts being compromised.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.