-
Notifications
You must be signed in to change notification settings - Fork 10.3k
ProtectedBrowserStorage throws CryptographicException occasionally when using PersistKeysToAzureBlobStorage and ProtectKeysWithAzureKeyVault #48848
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I also get this error intermittently that I documented on StackOverflow here and cannot figure out what the problem is. Mine does cause a major issue when it occurs. Login happens fine but then I get this error from all API calls from my Blazor WASM app. I believe it has something to do with caching on the client side but cannot figure out why or how to fix it. The only way to get the app functioning again (mine runs in an Azure App Service) is to restart it and make sure the first time I hit the site comes from a private browsing session, then it works fine. If I try from a regular browser window I get the same behavior and nothing works for any users until I restart and hit immediately from a private window. |
Thanks for contacting us. We're moving this issue to the |
We use somewhat the same configuration in our software:
We use the SetApplicationName to support multiple deployment slots on Azure. Otherwise our keys fail every time we switch slots. Next to that, we store the keys in the database. It is the same database IDSRV uses to store user credentials, so it is reachable by the application. At this moment we get intermittent errors as displayed above. But we suspect it has something to do with creating new keys. We have no specific settings in the IDSRV options:
We understand that the issue won't be resolved quickly, but it is a major issue for us. All user interaction with our system is stopped and also inter-application communication is stopped as we use IDSRV authentication there as well. Can we circumvent this for now by disabling the automatic key rotation? Or is there another way we could prevent the issue from happening? We use .Net 8.0 and IDSRV 7.0.1 Thanks in advance for thinking along. |
This is also a huge issue for our team. Pretty much all database access is halted until the user clears their localStorage. |
I have come across this problem as well. A .Net API project is using an instance of Identity Server for authentication. Between midnight and 2.a.m the users successfully create tokens, but moments later introspect returns that the tokens are inactive. There is an error logged between these 2 operations: The key {xxx} was not found in the key ring. For more information go to https://aka.ms/aspnet/dataprotectionwarning |
I'm going to close this issue. Please post additional feedback in #36157 so we can track it centrally and don't drop any. My apologies to anyone whose feedback was missed in the interim. |
Uh oh!
There was an error while loading. Please reload this page.
Is there an existing issue for this?
Describe the bug
Occasionally (25 times in last 30 days) users of my Blazor App are triggering an exception in our Azure hosted App Service.
Often times the app is working fine and I assume the key is being used to encrypt and decrypt the keys.
Expected Behavior
The App Service should always be able to access the key and the cryptographic exception should not occur.
Steps To Reproduce
I have followed this guide https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/configuration/overview?view=aspnetcore-7.0 and configure my Data Protection like so,
I believe my Azure access is configured correctly as it works fine for most of the time.
Exceptions (if any)
.NET Version
6
Anything else?
From the code in KeyRingBasedDataProtector it looks like it can access the key but the one with the specific ID is not found?
aspnetcore/src/DataProtection/DataProtection/src/KeyManagement/KeyRingBasedDataProtector.cs
Line 244 in d1f00b0
The text was updated successfully, but these errors were encountered: