We have code that uses default ASP.NET Identity logic for issuing reset tokens and this was working fine through our test environments until we hit a load-balanced multi-instance environment. Here we found that the reset token issued was tied to the instance it was generated on.
Our assumption is that this is related to the data protection wiring. There's an SO post here suggesting as much, and recommending we roll our own data protection provider. This is something I'm very keen to avoid.
I'd (presumably mistakenly) assumed that data protection used machine keys by default to ensure encryption is applied consistently across multiple instances (didn't I even read this somewhere once?). Anyway we do have machine keys shared across these instances.
I'm now (not) surprised to find the documentation around this is pretty vague given it must be an extremely common challenge. There is some suggestion that using services.AddDataProtection().SetApplicationName("unique-value");
would solve this but this doesn't appear to help.
It'd be great if anyone could explain this behaviour (why doesn't the default support a load-balanced environment) and suggest a solution that doesn't involve rolling our own encrpytion logic...
By the way, this is an old .NET 4.7.2 app.