Thanks for the explanation! I'm usually pretty sceptical when people step outside the stuff provided by whatever framework they're building on (something which devs at my workplace are always a little keen to do, which occasionally winds up in terms of things that need to be refactored/rewritten a few months down the track in a more standard way to integrate with some other component or whatnot) - so it's a bit of a compulsive habit to try to pick apart why the framework wasn't suitable. For MVC auth tokens though it seems to be a necessary thing to actually get a straightforward and neat solution.

It is a really nice solution, and I'm glad that you guys have pointed out that there's a problem and actually done something about it ("hey, just set the aspnet:UseLegacyEncryption / some other undocumented appsetting" isn't a legit solution), and further than that, opened it up (though it all seems to have disappeared now).

We wound up just more tightly controlling updates (and were fortunate to be in a position that this was a solution/the problem wasn't that major), but the backup was to serve auth cookies unencrypted and add/remove the encryption via a httpmodule - after all, it isn't forms authentication that was really 'broken' IMO, it was that Microsoft kept changing the implementation of encryption all the time. I get the impression that this could be a cleaner solution for asp.net, but definitely isn't for MVC - the next time we have to share auth tokens across multiple MVC apps / multiple instances that we don't control updates on, I'll be sure to pick up your code and run with it, so thanks.