Simple Comments Release Notes: v.960 (2/3) | WebReference

Simple Comments Release Notes: v.960 (2/3)

To page 1current pageTo page 3
[previous] [next]

Simple Comments Release Notes: v.960

The Current Process: Proving E-mail Ownership

Before jumping into OpenID, it may be helpful to first understand how Simple Comments currently verifies individuals (for those systems with visitor registrations enabled; systems that don't have visitor registrations enabled aren't verifying the individuals at all).

When a visitor signs up for an account with Simple Comments, they're required to provide their E-mail address. A message with a unique, randomly generated code is then sent to that address and is stored with the user's account registration information by Simple Comments. The user then confirms that they do in fact own that E-mail address by opening their E-mail client, retrieving the random code that was sent to them and providing that code to the script. Behind the scenes, Simple Comments compares the provided code to the code it originally stored for this E-mail address, and if the two match, proceeds as if the user has indeed provided a legitimate registration. This is a classic user verification scheme used by Simple Comments and many other Web applications that must somehow verify that a person is in fact the actual owner of some unique identifier. In this case, we prove that the user actually owns the E-mail address that they provided.1

What Is OpenID?

So what exactly is OpenID? According to the specifications:

OpenID Authentication provides a way to prove that an end user controls an Identifier. It does this without the Relying Party needing access to end user credentials such as a password or to other sensitive information such as an email address. OpenID Authentication 2.0

Note both the similarities and differences between the E-mail method described above, and OpenID verfications. In OpenID, we're attempting to prove that a user owns (controls) a particular, unique identifier; and if they do, we'll be willing to link their interactions on our site with that actual identifier. In the case of OpenID, the unique identifier isn't the user's E-mail address. Instead, OpenIDs are typically (but not exclusively; we'll come back to this point on the next page), URL addresses.

OpenID Authentication in a Nutshell

To prove that an individual is the owner (or that they control) a particular URL requires interactions between the user, the Relying Party (RP; that's the Web application or site that wants proof that the user owns the address). In OpenID terms, Simple Comments is a Relying Party, and the OpenID Provider (OP; that's someone who provides OpenID identifiers to individuals and is willing to interact with RPs to prove that the individuals control the identifiers they're claiming). Here's the process in brief:

  1. The user provides their OpenID identifier to a Web application (again, a Relying Party, or RP) that accepts OpenID logins.

  2. The RP performs discovery on the identifier, in an attempt to obtain the OP Endpoint URL--the URL the RP can contact to verify that the user does indeed control the identifier. Discovery might take several forms and steps; but can be as simple as performing an HTTP GET on the identifier provided and parsing the document returned as a result (the OP Endpoint URL will be provided within the document retrieved).

  3. Having obtained an OP Endpoint URL, the RP then redirects the user's browser to that URL, along with an extra parameter to indicate to the OP that we wish to verify the user's ownership of the identifier. We also send a return URL--which will be used by the OP after they've verified the user.

  4. The OP receives the request made through the user's browser, and verifies that the user does (or does not) control the ID they claim to own. How the OP does this isn't detailed in the OpenID specs; it could be a simple username and password designation, or it could be a more elaborate form of ID including digital certificates and/or authentication tokens.

  5. Having verified the individual, the OP redirects the user's browser back to the original RP, with the result of the verification as well as a signed hash of the verification message contents.

  6. Here's the critical part: The RP verifies the signed hash provided from the OP. This is done either directly, if the RP has already previously established a shared secret with this OP; or indirectly--by sending the whole message along with the signed hash back to the OP Endpoint URL they originally discovered for the OpenID in the first place. The OP then examines the message to ensure that it really was one that they sent (by comparing the hash provided to the one that they would have created for the message), and returns the result to the RP.

  7. If the hash is valid, the RP now knows it can trust the result of the OP's verification; and it also knows if the user is the owner of the ID that they claimed in the first place.

Those of you who have worked with OpenID in the past are probably squirming at this point; as I left a lot of details out of this process in the brief description above. I'm going to provide some further elaboration and musings on the protocol (and especially how it relates to Perl and Simple Comments) in the remainder of this article and in the forthcoming Part II of these release notes, but for those who prefer to get the details straight from the source, I refer you to, and specifically, the OpenID 2.0 Specifications.

OpenID Authentication in Pictures

If you had trouble following the traffic flow above, perhaps a quick pictorial overview might help. In the following example, we'll assume that is the Relying Party (or, more specifically, a script running on WebReference), Yahoo! is the OpenID Provider, and the OpenID to be validated is

The OpenID Identifier is provided to a login form
1. OpenID verification begins with a user providing an OpenID identifier in a login form.
In the form above, I've entered one of my OpenIDs,

Discovery on the identifier yields the endpoint
2. Behind the scenes, the Web application retrieves the document represented by the OpenID, and retrieves the OP Endpoint URL, which in this case is: Note that we actually had two choices in this example; the other Endpoint URL ( should be used strictly by older RPs that aren't capable of OpenID 2.0 authentications. You can see this document for yourself, if you like, by just hitting the OpenID URL directly (and doing a view-source on the results):

The user is then sent to the OP Endpoint URL, which in turn typically performs its own authentication on the user
3. The RP has redirected the user's browser to the OP Endpoint URL, which then (typically) authenticates the user using their own processes. Note that it's possible that the OP already knows the user is logged in; perhaps via some type of session cookie or other previously negotiated login method. That's one of the reasons the RP redirects the user's browser to the OP, instead of contacting them directly; so that the OP has full access to whatever cookies they had previously stored on the user's browser (and so that the authentication process itself--and especially the user's actual credentials--remain invisible to the RP). If the OP already knows the user is valid, they could return the user to the RP with a "user is valid" indication.

The OP now verifies that the user wants to login to the RP.
4. Having successfully authenticated the user, many OPs will take this extra step of verifying that the user truly does wish to login to the site represented by the Relying Party. This step is optional and isn't required by the OpenID specs.

Back to the RP. The RP verifies the hash signature, and if valid, accepts the user.
5. The OP has redirected the user's browser back to the RP, along with several additional pieces of information. Note especially the openid.sig, which the RP must validate before trusting the OP's response. In this case, we validated the sig by sending the entire contents of the message to the OP Endpoint URL (the one we originally discovered back in the second step) and asking them to confirm that this indeed was a sig that they created. As you can tell by the headline, this particular authentication was successful.

Try Your Own OpenID

You can see how this process works yourself by keying your own OpenID in our OpenID Test Script (this test script is also now included in the Simple Comments distribution file as openid_test.cgi). Don't have your own OpenID? They're easy enough to get. The site lists several well known OpenID providers, and you might already have an account with one or more of them that you can use as an OpenID! Feel free to try your OpenID in our test form, and let me know if you have any trouble. I was able to test several OpenID providers, but it's nearly impossible to test them all; so there might still be some idiosyncracies to work out.

Other OpenID Details

The above description represents the bare-bones process used to verify an OpenID; but as I mentioned earlier it's not exhaustive. On the next page, we'll continue our OpenID overview with a look at some of the implementation details that flesh out the full OpenID 2.0 specification...

1. Actually, all we've really proved is that the user has access to messages sent to the E-mail address that they provided. If multiple users share an E-mail address, or if a potential bad guy somehow has access to the raw E-mail traffic sent to the address (and it is unencrypted) then this proof of ownership isn't necessarily conclusive. Nonetheless, breaches such as these are rare enough to make this lightweight verification method viable (and bad guys could always just obtain their own E-mail addresses, removing the hassle of having to get access to someone else's E-mail traffic).

To page 1current pageTo page 3
[previous] [next]

Created: July 8, 2008
Revised: July 8, 2008