Web Auth: State of the art

Dan Connolly
$Revision: 1.3 $ of $Date: 2005/09/26 15:13:28 $

Access control in Web Architecture

• authentication is orthogonal to identity
  • contrast with capability architectures
• http has an extensible set of authenication schemes

Basic Authentication

1. Client to server: GET /sekret_page
2. Server replies: 401 insufficient credentials
   WWW-Authenticate: basic
3. Client to server: GET /sekret_page
   Auth: johndoe:hex(passwd)

Basic Auth Design Error

• enough round-trips for challenge-response auth
• ... but password in the clear*

* well, it's hex encoded, but the inverse function is well known

Digest Auth

• addresses password-in-the-clear with digest-based challenge/response
• facilitates kerberos-style auth services

Usability

• password dialogs built-in to browsers don't convey brand/trust
• providers use forms with <input type="password" />

Market forces

suppose you want to launch "my photo service"...

• 90%: "another username/password? no thanks"
• eventually, yahoo buys you

XML Sig

• signed documents, not just secured connections

Signed Forms

• client-signed documents
• seems to suffer from PKI deployment limiations; works in enterprises, but not in the wild

OpenID

OpenID

1. client: GET /sekret_page
2. openID consumer: (hmm... not sure... I think they redirect...)
3. openID consumer presents a form: please enter OpenID URI
4. client: my openID is http://fred.example/me
5. consumer GETs http://fred.example/me and looks for a link to a server <link rel="OpenID.Iforget" href="http://ids-r-us.example/svc" />
6. consumer redirects to server
7. client authenticates to server
8. server redirects client to consumer, assures (via arguments in the URI) consumer that client owns http://fred.example/me