Skip to content

How Does OpenID Work?

I’ve heard about OpenID on a podcast I listen to. Sounds interesting – an open source solution to have a ‘single sign on’ for many websites. Interested to see how this works – both as a user, and as a website author.

Here’s a run through of an example authentication:

  1. User accesses an OpenID enabled website, site responds with a form requesting the user’s OpenID identity.
  2. User enters their identity, e.g: russau.myopenid.com. Then submits the form to the website.
  3. Website server accesses http://russau.myopenid.com.
  4. Retrieves the location of the OpenID provider from the link tag:

    <link rel="openid.server" href="http://www.myopenid.com/server" />
  5. Website POSTs an ‘associate’ request to the provider. The two machines establish a secret using a Diffie-Hellman key exchange.
    openid.mode associate
    openid.assoc_type HMAC-SHA1
    openid.session_type DH-SHA1
    openid.dh_consumer_public
    openid.dh_modulus
    openid.dh_gen Ag==
  6. Provider’s response provides the website an ‘assoc_handle’ (and expiry) for future requests. The two servers now have established a shared secret, without passing it over the wire.
  7. assoc_handle {HMAC-SHA1}{47b0ec92}{5hMN8A==}
    assoc_type HMAC-SHA1
    dh_server_public
    enc_mac_key
    expires_in 1209600
    session_type DH-SHA1
  8. The comsumer’s response from step 2 contains a redirect to the provider, containing a number of parameters in the querystring. Note, the querystring contains the established ‘assoc_handle’, and a ‘nonce’ has been attached onto the ‘return_to’.
    openid.mode checkid_setup
    openid.identity http://russau.myopenid.com/
    openid.return_to http://openidconsumer.test/cp/login.aspx?&nonce=vovudmLa
    openid.trust_root http://openidconsumer.test/cp
    openid.assoc_handle {HMAC-SHA1}{47b0ec92}{5hMN8A==}
    openid.sreg.required gender,postcode,timezone
    openid.sreg.optional email,country
    openid.sreg.policy_url
  9. The user is now on the provider website, and performs the step needed to authenticate, e.g. entering a password.
  10. The provider redirects the user back to the consumer website, along with parameters in the querystring. The consumer now has everything it needs to log in the user.
    nonce vovudmLa
    openid.assoc_handle {HMAC-SHA1}{47b0ec92}{5hMN8A==}
    openid.identity http://russau.myopenid.com/
    openid.mode id_res

    openid.op_endpoint http://www.myopenid.com/server
    openid.response_nonce 2008-02-12T00:47:53ZyUUam3
    openid.return_to http://openidconsumer.test/cp/login.aspx?nonce=vovudmLa
    openid.sig EpvWdJtxacv2WtCaZLbud85M84k=
    openid.signed assoc_handle, identity, mode, op_endpoint, response_nonce, return_to, signed, sreg.country, sreg.email
    openid.sreg.country AU
    openid.sreg.email testuser@webmail.com

    This querystring contains a couple of things to prevent an attacker from spoofing it. The ‘assoc_handle’ established in steps 5 and 6, the consumer uses to this look up the established secret. ‘openid.sig’ contains a digital signature of the parameter values listed in ‘openid.signed’, using the established secret. If an attacker were to change the ‘openid.identity’ in an attempt to login as someone else, the signature wouldn’t match (without knowing the secret, the attacker cannot re-create the signature). Finally, the initial ‘openid.return_to’ in step 7 contained a nonce. If an attacker were to resubmit the querystring above unchanged (a replay attack), the consumer web site would know the nonce has already been used.

Further reading

{ 4 } Comments

  1. Parijat Bansal | August 12, 2008 at 9:59 am | Permalink

    Thanks a lot for the very easy to understand summary covering request and response formats. It would be great if you can elobrate the role of encryption.

  2. Russ | August 13, 2008 at 6:53 am | Permalink

    hi Parijat,
    there's not actually any "encryption" going on here. in steps 5 & 6 the two servers establish a "shared secret" using a Diffie-Hellman key exchange. in step 9 the OpenID enabled website receives a querystring that contains a signaure using this “shared secret”. so the website server can be 100% confident the querystring has come from the same server it talked to in step 5.

  3. StatiK EffecK | June 4, 2009 at 1:37 pm | Permalink

    I should mention that with OpenID 2.0 specifications, the consumer and provider can now be the same entity, for example, Google or MySpace. And instead of end-users using a URL as an OpenID, they can click a button that says "Log in with Google" and be redirected to Google page to log in, and be redirected back to the original page logged in. This is a huge step because users don't need to set up anything different if they already have a Google, Myspace, Yahoo, etc. account.

  4. Russ | June 5, 2009 at 3:50 am | Permalink

    Hi StatiK EffecK – this is a very cool feature of openid called "directed identity" – google mention it on their blog post here: http://google-code-updates.blogspot.com/2008/10/moving-another-step-closer-to-single.html

    More interesting stuff google is doing with openid here: http://google-code-updates.blogspot.com/2009/05/google-openid-api-taking-next-steps.html

Post a Comment

Your email is never published nor shared. Required fields are marked *