I had an MVC4 application (the new Whisky Fringe Tasting Tracker site) for which forms authentication’s persistent cookies worked fine when testing on my local machine but failed when deployed to my shared .NET host.

The symptom was pretty simple – you’d log in ticking the ‘remember me’ checkbox (which generates a persistent cookie on the client’s machine), could use the site normally but would find that the next day you were no longer logged in. In fact, leaving just 20 minutes or so between accesses to the site would be enough to see your login bumped.

That 20 minutes should have been a good clue – it’s about the same amount of time as the shared host’s app pool worker processes were recycling. With a bit of digging, what seemed to be happening was that in recycling the worker processes, my application was getting new validation and encryption keys, as at the machine.config level these were configured to auto-generate. With authentication cookie validation turned on, this meant that the keys used to sign and encrypt the cookie 20 minutes ago ain’t the same ones that were used to try to decrypt and validate it just now, so the provider kicks your login out.

The fix is to specify a machineKey element in your app’s web.config file under the <system.web> element, locking down a validation key and a decryption key to be used and opting you out of automatic key generation in the process. With this applied, logins will persist even over app pool recycles.

One caveat – if you use a tool such as this one to generate the keys for you, make sure that the ‘validation’ attribute that specifies the validation algorithm to use for tamper-proofing the cookies matches the default for the system as it was before if you’re using the System.Web.Providers libraries for authentication. Failure to do so will make it impossible for existing users to login… The default is ‘HMACSHA256’.