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

Post a Comment

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