« Home | Facebook dev, IIS 5.1, and error 405 » | Creating Your Own Dev SSL Cert for IIS » | Moving from ASP.NET 1.1 to 2.0 » | Link Drop VI » | Silverlight createFromXaml Bug » | C# command line parser? » | Firefox extension: CookiePie » | Hand-held browser » | Silverlight » | Google Finance » 

Tuesday, February 12, 2008 

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.modeassociate
    openid.assoc_typeHMAC-SHA1
    openid.session_typeDH-SHA1
    openid.dh_consumer_public
    openid.dh_modulus
    openid.dh_genAg==
  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_typeHMAC-SHA1
    dh_server_public
    enc_mac_key
    expires_in1209600
    session_typeDH-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.modecheckid_setup
    openid.identityhttp://russau.myopenid.com/
    openid.return_tohttp://openidconsumer.test/cp/login.aspx?&nonce=vovudmLa
    openid.trust_roothttp://openidconsumer.test/cp
    openid.assoc_handle{HMAC-SHA1}{47b0ec92}{5hMN8A==}
    openid.sreg.requiredgender,postcode,timezone
    openid.sreg.optionalemail,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.
    noncevovudmLa
    openid.assoc_handle{HMAC-SHA1}{47b0ec92}{5hMN8A==}
    openid.identityhttp://russau.myopenid.com/
    openid.modeid_res
    openid.op_endpointhttp://www.myopenid.com/server
    openid.response_nonce2008-02-12T00:47:53ZyUUam3
    openid.return_tohttp://openidconsumer.test/cp/login.aspx?nonce=vovudmLa
    openid.sigEpvWdJtxacv2WtCaZLbud85M84k=
    openid.signedassoc_handle, identity, mode, op_endpoint, response_nonce, return_to, signed, sreg.country, sreg.email
    openid.sreg.countryAU
    openid.sreg.emailtestuser@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

Labels: ,

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.

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.

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.

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