Five Minutes or less: OpenID

Most of the technical people I work with know what SAML is and how it works and how the federation protocols for SAML work (SP initiated, IdP initiated, Browser Artifact, Browser POST). OpenID is much less well known.

So here's what you need to know about OpenID in five minutes or less.

In OpenID there are three parties:

• The user and their browser.
• The Relying Party (sometimes abbreviated to RP) is the web site that's asking the user to authenticate. In SAML this is the Service Provider.
• The OpenID Provider (sometimes abbreviated OP) is the web site that's going to vouch for the user. In SAML this is the Identity Provider

Many people use the SAML and OpenID terms interchangeably when talking about the OpenID parties but I'll try to remember to stick with the right ones for this post.

OpenID works a whole lot like SAML's SP Initiated Browser POST authentication except for these differences:

1. All user interactions are via HTTP GET
2. The RP and OP communicate directly with each other via HTTP

Here's a simplified view of the flow:

I've broken the flow into three stages:

1. Choose OP
2. Login @OP
3. AuthN

Note: these are my own divisions and names; the OpenID standard doesn't break the flow up and doesn't have names for what I call stages.

Stage 1: Choose OP
The first step in the OpenID flow is the user telling the Relying Party which OpenID Provider they would like to use, often though the NASCAR style row of buttons. Under the covers each of those buttons corresponds to a URL and when you click the button the HTML form is actually submitting the URL to the Relying Party's web site. In some cases the site will allow you to enter a URL of your choosing.

When you send the URL to the site the Relying Party checks to see if it "likes" the OpenID Provider (usually by checking against a list of providers). If the URL looks OK the RP makes an special HTTP request, called an XRDS request, to the OP. The OP returns back a bunch of data describing the OP including the features and functionality that the OP offers.

A couple of other things happen here, but in the interest of time I'm going to skip over them.

If everything looks OK the RP redirects the user to the OP with an Authentication Request (via an HTTP GET with the data in the query string).

Stage 2: Login @ OP
When the user sends their Authentication Request to the OP the OP makes the user login. If the user has already logged in to the OP then that step might be skipped.

After the user has authenticated to the OP the OP generates an authentication response for the RP and redirects the user back to the RP.

Stage 3: AuthN
Finally... the user presents that authentication response to the RP (via an HTTP GET). The RP checks it out and if it's "good" then the user is considered logged in.

Finally the RP returns the content, application or whatever it is that they were trying to do at the RP in the first place.