State parameter checking and HttpRuntime.Cache

[pg94au]

I've been working on integrating this authentication module into an existing application, and noticed something that will cause a problem for us. From a look into the code, when the state parameter is generated to be included in the original redirect query string, the state is then held locally in HttpRuntime.Cache. If either the request containing the auth code does not get sent back to the same server (in a multi-server environment), or if the application gets unloaded and restarted before the auth code comes back, the cache will not contain the expected state. Do you have suggested work-around for this?

As the use of state is marked as 'recommended' in the OpenID Connect Core 1.0 spec, perhaps an options flag for the usage of state could be implemented, with the default being to enforce state checking. Additionally, a hook to provide a means of configuring a state provider/manager could also be useful for applications that have their own method for handling shared storage between servers.

What are your thoughts about this? Would you be receptive of such changes?

[ghost]

@pg94au We ended up using identity server instead of keycloak so I haven't looked at this in a while. I would be receptive to your changes.