If you’re writing an OpenID Provider, you should have a strong appreciation for the security of your customers’ identities that you will be protecting. One aspect of that protection is against replay attacks, where a man-in-the-middle sniffs the identity assertion from a Provider and replays it against the same relying party and manages to log in as the victim. OpenID 2.0 provides built-in protection against replay attacks, but that leaves OpenID 1.x users vulnerable.
The recent OpenID Providers hosted by the big Yahoo!, Google and Microsoft have mitigated against the security problems in OpenID 1.x by refusing to log their users into OpenID 1.x relying parties. This is secure for their users, but less helpful in getting them to log into those sites. There are still quite a few OpenID 1.x relying party web sites out there. It would be great if we could allow them to log in and yet still offer them protection.
It turns out that replay protection for OpenID 1.x is not new. On the relying party side, replay protection can be added with custom parameters added to the return_to parameter of the authentication request. The Janrain OpenID and DotNetOpenId libraries do this already. But since not all OpenID 1.x relying parties can be relied on to have implemented their own replay protection, an OpenID Provider cannot assume any particular relying party is safe unless it is an OpenID 2.0 site.
New with DotNetOpenAuth (a.k.a. DotNetOpenId v3.0) there is a way to have your cake and eat it too. OpenID Providers that use DotNetOpenAuth as their OpenID library will provide replay protection for all their users, regardless of the OpenID version supported by any arbitrary relying party web site. It does this by refusing to use a shared association during authentication if that authentication request comes from a 1.0 RP. Instead, it generates its own private association and changes the assoc_handle parameter in the response. The RP is then forced to verify the assertion by calling back to the Provider. This is where the Provider can apply its own replay protection, which is exactly what it does.
With replay protection now extended to all versions of OpenID relying parties, it seems that the only security hole left in OpenID 1.x that would justify a Provider in refusing to work with them is RP site verification (a.k.a. RP discovery). But to date every Provider, even the big ones previously named, work with OpenID 2.0 RPs even if they don’t happen to support RP discovery, so this isn’t even an issue.
Will we see Yahoo! and others start working with 1.x OpenID RPs? I doubt it. But I think they could (securely) if they wanted to.