views:

97

answers:

2

I'm adding optional OpenID authentication to the system. Everything works smoothly with DotNETOpenID. Yet, I get an issue when:

  1. User logs into the web application using a standard login (FormsAutentication)
  2. User associates some OpenID with the account (we use programmatic OpenID logon here to get the claimed identity)
  3. User logs out of the FormsAuthentication and logs back in with the OpenID (using the Login control).

At the last step we get a replay attack error. I suspect that OpenID persists some information in the application store (to be used for requests) which is used to get the previous request, instead of starting a new one.

Could anyone help shed some light on the problem here?

If the issue is how I've understood it, how could I cleanup this specific state information after successfully binding the OpenID to account using the programmatic login (given that I've got successful request at hand)?

+2  A: 

Which Provider are you testing against? Honestly it sounds like the most likely guilty party in this case since it makes up the openid.response_nonce value. Another likely place to look is are you (by chance) maintaining all the openid.* querystring parameters in the URL between the first and second logins? For example, at the second login page before the user enters their OpenID, are their openid.* parameters in the URL of the page? If so, that's likely the problem and it can be fixed by your programmatic page causing a clean redirect to get rid of them after a login attempt.

Andrew Arnott
A: 

Ok, the the actual problem seems to go away after adding Session.Abandon() (and cleaning up auth logic a bit) between the moment of first OpenID assignment and actual authentication with it.

Rinat Abdullin