Closed neurospeech closed 6 years ago
In previous ASP.NET, we were caching Authentication module to improve speed, e.g.
Do you mean you wrote your own AuthenticationModule that did caching?
IMHO, that's actually a very good idea.
The same caching concept should/could also apply to the bearer middleware. I remember the Thinktecture guys implemented a similar thing in their validation middleware, and it's definitely a great feature.
@Tratcher I guess it would be similar, but with a major difference: the session store you're mentioning is meant for reference cookies, which means that decrypting cookies won't work when the store is cleared. Caching doesn't have the same objective: it will only help reduce the CPU cost of the cryptographic operations required to verify/decrypt the ticket by caching the claims corresponding to a token/cookie, but will have no influence on the final size of the cookie/token. Verifying/decrypting the ticket should work even if the cache has been cleared.
@PinpointTownes I know they aren't the same, but the reference mode could be another way of avoiding the crypto overhead.
Another way of adding this would be as a wrapper around the ISecureDataFormat used in CookieAuthOptions.TicketDataFormat
Sure, you can always implement that yourself, but I guess the OP was looking for a built-in thing.
Closing this issue because we have no plans to implement this. If we are presented with concrete performance data we will reconsider.
In previous ASP.NET, we were caching Authentication module to improve speed, e.g.
This is psedo code.
This results in improved performance as we are reducing request life cycle's authentication part by caching it for 5 mins.
Instead of HttpRuntime.Cache, we can create a configurable MemoryCache, in Cookie Authentication module, that can cache authorizations in memory for short lived period. This reduces decryption and validation for small amount of time.