DotNetOpenAuth: Message signature was incorrect

Question

I\'m getting a \"Message signature was incorrect\" exception when trying to authenticate with MyOpenID and Yahoo.

I\'m using pretty much the ASP.NET MVC sample code

Answer 1

All this discussion revolves around the following question:

How does Relying Party (RP) make sure the request containing the authentication token is coming from the OP(OpenId Provider ) to which he forwarded the user’s request to?

Following steps explains how it happens

1. User Request comes to the Replying Party (RP), our website in our case
2. Application stores a unique signature corresponding to this user in a local signature store (LSS) and then embeds this signature in the Message and forward this Message to OpenId Provider(OP)
3. User types his credentials and the OP authenticates his Message and then forwards this Message, which has the signature still embedded in it, back to RP
4. RP compare the signature which is embedded in the Message to the signature which is in LSS and if they match RP authenticate the user

If the LSS vanishes (somehow) before the Message comes back from OP there is nothing for RP to compare the signature with thus it fails to authenticate user and throws error: Message signature was incorrect.

How can LSS Vanish:

1. ASP.net refreshes the application pool
2. IIS is restarted
3. In web farm the Message is served by application hosted on different server

Two solutions to this issue:

1. RP run’s in dumb mode

   a. It does not store and signature locally and thus does not use signature comparison to make sure the Message is coming from the OP to which he forwarded the user to for authentication

   b. Instead, once RP received the authentication Message from the OP it send the Message back to OP and ask him to check if he is the one who has authenticate this user and is the originator of the Message. If OP replies Yes I am the originator of this Message and I have created this message then the user is authenticated by RP

2. Implement your own persistence store that does not vanish, not matter what ASP.net does to the process, much like using SQL to store session state.

Answer 2

We fixed this issue by implementing IRelyingPartyApplicationStore (IOpenIdApplicationStore in newer versions of DotNetOpenAuth) and adding the store class name to the .config

<dotNetOpenAuth>
  <openid ...>
    <relyingParty>
      ...
      <store type="some.name.space.MyRelyingPartyApplicationStore, some.assembly"/>
    </relyingParty>
  </openid>
  ...
</dotNetOpenAuth>

The interface is a composition of two other interfaces with five members all together.

/// <summary>
/// A hybrid of the store interfaces that an OpenID Provider must implement, and
/// an OpenID Relying Party may implement to operate in stateful (smart) mode.
/// </summary>
public interface IOpenIdApplicationStore : ICryptoKeyStore, INonceStore
{
}

We used dumb mode as a quick fix to get up an running, but in the end you'll probably want something like this.

Answer 3

Turns out this was an issue with using DotNetOpenAuth in a web farm environment.

When you create your OpenIdRelyingParty make sure you pass null in the constructor.

This puts your web site into OpenID stateless or 'dumb' mode. It's slightly slower for users to log in (if you even notice) but you avoid having to write an IRelyingPartyApplicationStore to allow DotNetOpenAuth to work across your farm;

var openIdRelyingParty = new OpenIdRelyingParty(null);