OpenID best implementation practices?

[Carl Howells]

Johannes Ernst wrote:
> 1) is there a "best practice" that OpenID implementations should  follow 
> in order to avoid replay attacks? I suspect the trick is to  create a 
> Relying Party (aka return_to) URL that contains a nonce, and  track the 
> uses of that nonce?
> 
> E.g. if the Relying Party is
>     http://rp.example.com
> use
>    http://rp.example.com?my-nonce=<random-number>
> as the return_to URL in the forward leg of the authentication, and  
> check the my-nonce parameter on the return leg for whether or not it  
> was taken already?

That's essentially what I believe to be the best approach, though there 
is additional flexibility possible.  Our OpenID library provides the 
relying party with a token (containing the nonce and some additional 
information) that it is responsible for associating with the request in 
whatever manner is most appropriate for its application.

Many applications have the concept of a session, even for 
non-authenticated users, which is a good spot to store the token.  Other 
applications may choose to store the token in a cookie, or make it part 
of the return_to URL for that request.

But in any case, the idea is the same:  store a nonce somewhere, and 
verify that it hasn't been used when a response comes back that tries to 
use it.

> Does that mean we could use the same mechanism that we are using in  
> LID, or is a different approach more appropriate for OpenID?

The biggest difference is that LID's approach is specified by the 
protocol, but OpenID's is left to implementations.  That means that the 
one-way nonce idea won't work with the current version of OpenID, as it 
requires both the server and the relying party to use the same mechanism.

> 2) is there a "best practice" for single sign-OUT (not -IN). It is  
> relatively straightforward to keep track of all the Relying Parties  at 
> which I have authenticated during the current session, but other  than 
> visiting each of them manually and looking for the OpenID Logout  button 
> on each of them, can I automate this from one big button "log  out 
> everywhere"?

That's currently not possible.  See the discussion in part of this old 
thread: http://lists.danga.com/pipermail/yadis/2005-July/001060.html

> 3) Is the threat model against OpenID documented somewhere? I'm  missing 
> the rationale for some of the URL arguments, such as why  
> openid.return_to is returned on the back leg of the authentication  
> redirects, or why some of fields should or should not be signed.

I don't think there's any one document that contains everything.  I'd 
recommend looking at mailing list archives, especially for messages from 
Paul Crowley, and the ones he responded to.

> Of course, everybody might be on vacation ...

Not everybody. :)


Carl Howells