azure-activedirectory-identitymodel-extensions-for-dotnet
azure-activedirectory-identitymodel-extensions-for-dotnet copied to clipboard
Support offline signature validation
The official Key Vault docs around signature verification (https://docs.microsoft.com/en-us/azure/key-vault/about-keys-secrets-and-certificates) state "Verification of signed hashes is supported as a convenience operation for applications that may not have access to [public] key material. For best application performance, verify that operations are performed locally."
The KeyVaultSignatureProvider class makes an HTTP call (client.VerifyAsync) for every signature validation. It would be good if the key was cached and signature validation was done locally instead. As it stands now, we are using Key Vault signature verification with some custom authentication scheme so every single protected request now results in an additional HTTP call.
@briandunnington this should be possible as signatures use public keys.
@brentschmaltz Yes, it is possible to 'roll my own' logic and do the signature verification by grabbing the key and doing it myself. But it would be nice if the extension did this automatically which is why I raised it here.
@briandunnington is this still a feature you would use and need? what are the impacts with latency?
@jennyf19 We ended up rolling our own implementation to replace the KeyVaultSignatureProvider implementation. In our implementation, we grab the key vault key and then do the verification locally instead of letting it call out to key vault each time.
for our use case, we issue and sign a custom JWT which we use for authentication in our API endpoints. with the default implementation, each request requires a call to key vault to validate the JWT signature which took ~80-100ms. When you times that by millions of requests a day, it really adds up, especially when the rest of the API processing only takes <100ms total. By doing the signature validation with a local key, the latency is essentially erased completely.
so yes, we would still use this, but have been using our custom implementation for the last 4+ years successfully so it is not pressing.