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:
- User accesses an OpenID enabled website, site responds with a form requesting the user's OpenID identity.
- User enters their identity, e.g: russau.myopenid.com. Then submits the form to the website.
- Website server accesses http://russau.myopenid.com.
- Retrieves the location of the OpenID provider from the link tag:
<link rel="openid.server" href="http://www.myopenid.com/server" />
- 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== |
- 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 |
- 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 | |
- The user is now on the provider website, and performs the step needed to authenticate, e.g. entering a password.
- 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
Labels: security, web dev