Tin Isles

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.

assoc_handle	{HMAC-SHA1}{47b0ec92}{5hMN8A==}
assoc_type	HMAC-SHA1
dh_server_public
enc_mac_key
expires_in	1209600
session_type	DH-SHA1

7. 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

8. The user is now on the provider website, and performs the step needed to authenticate, e.g. entering a password.
9. 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

• OpenID Authentication 1.1
• OpenID Simple Registration Extension 1.0
• dotnetopenid – C# implementation of OpenID consumer and provider
• OpenIDSpecification