Single Sign-On: The OpenID Protocol

Single Sign-On: The OpenID Protocol

In one of the previous posts, we explained SSO on the example of SAML.In this post, we will introduce another popular and widely deployed SSO Protocol: OpenID(if you are not familiar with SSO, we recommend you to read SSO on the example of SAML first).

The OpenID protocol exists in different versions. While OpenID 1.0 and 1.1 are still supported and deployed in the WWW, most implementations concentrate on OpenID 2.0 – so does this post.



We use the following notation for a cleared parameter intent. If you have worked on OpenID before, you may be more familiar with the OpenID specific parameter values, so here is an overview:

URL.IDC openid.claimed_id The identity requested by the Client C. In the context of OpenID, the identity is a URL e.g
URL.SP openid.return_to The URL of the Service Provider (SP), e.g.
URL.IdP openid.op_endpoint The URL of the Identity Provider (IdP), e.g.
α openid.assoc_handle The value that identifies the signature verification key stored on the SP as well as on the IdP.
σ openid.sig This parameter contains the value of the token's signature. In fact, OpenID uses a Hash MAC (and not a signature), but has the OpenID specification uses the term “signature”, this Post will do this as well.

There are a lot more parameters in OpenID:
  • openid.ns defines the used protocol version, e.g.
  • openid.response_nonce contains a timestamp suffixed with a nonce value
  • openid.signed holds the parameter names that are signed, e.g. claimed_id, return_to,..
  •*, openid.sreg.* are extension parameters that can be used to transfer additional information, e.g. an email address or a birthday.
For a better understanding of the protocol flow, we only use the parameters mentioned in the table above in this Post.

OpenID Protocol Flow