The OpenId Sequence Diagram

OpenId very neatly solves the global identity problem within the constraints of working with legacy browsers. It is a complex protocol though as the following sequence diagram illustrates, and this may be a problem for automated agents that need to jump around the web from hyperlink to hyperlink, as hyperdata agents tend to do.

The diagram illustrates the following scenario. Romeo wants to find the current location of Juliette. So his semantic web user agent GET's her current foaf file. But Juliette wants to protect information about her current whereabouts and reveal it only to people she trusts, so she configures her server to require the user agent to authenticate itself in order to get more information. If the user agent can prove that is is owned by one of her trusted friends, and Romeo in particular, she will deliver the information to it (and so to him).

The steps numbered in the sequence diagram are as follows:

  1. A User Agent fetches a web page that requires authentication. OpenId was designed with legacy web browsers in mind, for which it would return a page containing an OpenId login box such as the one to the right. openid login box In the case of a hyperdata agent as in our use case, the agent would GET a public foaf file, which might contain a link to an OpenId authentication endpoint. Perhaps with some rdf such as the following N3:
    <> openid:login </openidAuth.cgi> .
    Perhaps some more information would indicate which resources were protected.
  2. In current practice a human user notices the login box and types his identifying URL in it, such as This is the brilliant invention of OpenId: getting hundreds of millions of people to find it natural to identify themselves via a URL, instead of an email. The user then clicks the "Login button".
    In our semantic use case the hyperdata agent would notice the above openid link and would deduce that it needs to login to the site to get more information. Romeo's Id ( perhaps ) would then be POSTed to the /openidAuth.cgi authentication endpoint.
  3. The OpenId authentication endpoint then fetches the web page by GETing Romeo's url This returned representation contains a link in the header of the page pointing Romeo's OpenId server url. If the representation returned is html then this would contain the following in the header
     <link rel="openid.server" href="" />
  4. The representation returned in step 3, could contain a lot of other information too. A link to a foaf file may not be a bad idea as I described in foaf and openid. The returned representation in step 3 could even be RDFa extended html, in which case this step may not even be necessary. For a hyperdata server the information may be useful, as it may suggest a connection Romeo could have to some other people that would allow it to decide whether it wishes to continue the login process.
  5. Juliette's OpenId authentication endpoint then sends a redirect to Romeo's user agent, directing it towards his OpenId Identity Provider. The redirect also contains the URL of the OpenId authentication cgi, so that in step 8 below the Identity Provider can redirect a message back.
  6. Romeo user agent dutifully redirects romeo to the identity provider, which then returns a form with a username and password entry box.
  7. Romeo's user agent could learn to fill the user name password pair in automatically and even skip the previous step 6 . In any case given the user name and password, the Identity Provider then sends back some cryptographic tokens to the User Agent to have it redirect to the OpenId Authentication cgi at
  8. Romeo's Hyperdata user agent then dutifully redirects back to the OpenId authentication endpoint
  9. The authentication endpoint sends a request to the Openid Identity provider to verify that the cryptographic token is authentic. If it is, a conventional answer is sent back.
  10. The OpenId authentication endpoint finally sends a response back with a session cookie, giving access to various resources on Juliette's web site. Perhaps it even knows to redirect the user agent to a protected resource, though that would have required some information concerning this to have been sent in stage 2.
  11. Finally Romeo's user agent can GET Juliette's protected information if Juliette's hyperdata web server permits it. In this case it will, because Juliette loves Romeo.

All of the steps above could be automatized, so from the user's point of view they may not be complicated. The user agent could even learn to fill in the user name and password required by the Identity Provider. But there are still a very large number of connections between the User Agent and the different services. If these connections are to be secure they would need to protected by SSL (as hinted at by the double line arrows). And SSL connections are not cheap. So the above may be unacceptably slow. On the other hand it would work with a protocol that is growing fast in acceptance.

It is is certainly worth comparing this sequence diagram with the very light weight one presented in "FOAF & SLL: creating a global decentralised authentication protocol".

Thanks again to Benjamin Nowack for bringing the discussion on RDFAuth to thinking about using the OpenId protocol directly as described above. See his post on the semantic web mailing list. Benjamin also pointed to the HTTP OpenID Authentication proposal, which shows how some of the above can be simplified if certain assumptions about the capabilities of the client are made. It would be worth making a sequence diagram of that proposal too.


I`v been carefully studying OpenID protocol flow for my essay (i`m a student). I only start to understand how it works, but let me ask a question.

Step 10 says that access to resources is finally given, but why in the diagram hyperdata Client still receives http status code 401, which is - Unauthorized?

Could you please be more specific on this or provide me with more information on what happens there?

Posted by Jencha on May 02, 2008 at 01:23 PM CEST #

Hi Jencha, thanks for your comment. You are right I mistakenly wrote 401 redirects instead of 303. Probably a copy/paste mistake from a previous slide.

This is fixed now.

Thanks for the feedback. (I'll fix my JavaOne slides too...)

Posted by Henry Story on May 02, 2008 at 04:47 PM CEST #


A quick question about the diagram itself :

- what is the significance of the different arrow tails on the message calls? (single line, double line and dashed)

Posted by Yanic on August 11, 2008 at 01:37 PM CEST #

Good question Yanic :-) I should have mentioned that.

I was thinking like this:
- the single line arrow tails are for HTTP connections
- the double line arrow tails are for HTTPS connections (an https connection is thicker, it requires some chit chat between the client and server
- the dashed arrow was to signify that this step was perhaps optional

Step 4 is optional because the returned representation in 3 could contain the information required. This would be the case if the openid page contained the information in the foaf file.

This is what Tim Berner's Lee has done

His home page, is his openid page, and it contains his foaf information. Using more recent standards, he could have marked up his home page with RDFa markup.

By the way I should note that the above is the above sequence diagram is OpenId enhanced from a foaf perspective. Step 4 is not part of the official OpenId spec. But it is not precluded either.

Posted by guest on August 11, 2008 at 10:32 PM CEST #

Ah, now I get it. I have an interest in all things sequence diagrams, because of this <a href="">sequence diagram editor</a> I've created.

Perhaps I can make some some suggestions to better express your intent without leaving UML country? Why not :

- use an opt combined fragment for the optional part. You can find an example in <a href="">this tutorial</a> (see 'Conditional interaction' section)

- use a <<secure>> stereotype for the secure communication.

Thanks for the explanation!

Posted by Yanic on August 12, 2008 at 01:24 PM CEST #

Nice sequence diagram! Is this sequence diagram still valid for the OpenID 2.0 standard?

Posted by jarno on January 10, 2009 at 08:13 AM CET #

Jarno, I am not absolutely sure if this is OpenId 2.0 or only 1.0. It's a long time ago I drew this. If someone knows, and can point out any differences - if any - that would be appreciated. I am too busy working on foaf+ssl now to worry.

Posted by Henry Story on January 10, 2009 at 01:10 PM CET #

these are not avialable in aperticular book

Posted by gopalrao on September 30, 2009 at 11:40 PM CEST #

Post a Comment:
Comments are closed for this entry.



« July 2016