You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
JwtTokenService is a scoped service and it doesn't have any locking mechanisms.
In case a credential needs to be created (for example on first start or credential expire) it will create as many keys as there are concurrent simultaneous requests.
This is an issue because:
Why my system now has 2 or more keys?
If amount of requests is huge you can create a huge amount of keys. In case you create >AlgorithmsToKeep you will have an issue to validate tokens because JwtServiceValidationHandler will not return the keys to you.
To resolve JwtTokenService might need to become a singleton, resolve IJsonWebKeyStore from a scope and apply some locking.
For optimization you can apply double-locking only if the key is subject to be renewed.
For now I made a workaround like this (somewhere in a singleton returning access tokens):
This is a bit not ideal as it always locks but better than having lots of tokens created at the same time.
BTW GetCurrentSigningCredentials() I think should also accept CancellationToken as DB store can have some time to create creds and user might already cancel his login?
The text was updated successfully, but these errors were encountered:
JwtTokenService is a scoped service and it doesn't have any locking mechanisms.
In case a credential needs to be created (for example on first start or credential expire) it will create as many keys as there are concurrent simultaneous requests.
This is an issue because:
AlgorithmsToKeep
you will have an issue to validate tokens because JwtServiceValidationHandler will not return the keys to you.To resolve JwtTokenService might need to become a singleton, resolve IJsonWebKeyStore from a scope and apply some locking.
For optimization you can apply double-locking only if the key is subject to be renewed.
For now I made a workaround like this (somewhere in a singleton returning access tokens):
This is a bit not ideal as it always locks but better than having lots of tokens created at the same time.
BTW
GetCurrentSigningCredentials()
I think should also acceptCancellationToken
as DB store can have some time to create creds and user might already cancel his login?The text was updated successfully, but these errors were encountered: