Azure-activedirectory-identitymodel-extensions-for-dotnet: Extensibility for signing and encrypting tokens with Azure Key Vault.

[CBaud]

Summary
The current library provides an extensible model for custom signing and encryption solutions. This makes it possible to create tokens that are backed by cloud-based security keys, such as Azure Key Vault. I think it would be helpful to create a new project that provides the base implementation to create those types of tokens.

Proposed Implementation
_KeyVaultSignatureProvider_: This class will derive from SignatureProvider, and will use an IKeyVaultClient instance and a key identifier string to perform signing and encryption operations via Azure Key Vault.
_KeyVaultCryptoProviderFactory_: This class will derive from CryptoProviderFactory, and will use an IKeyVaultClient instance to search for the cloud-based security keys and pass them along to the SignatureProvider instances it creates.

Dependencies
_Microsoft.Azure.KeyVault 2.3.2+_: This library enables interactions with Azure Key Vault.
_Microsoft.Azure.Services.AppAuthentication 1.0.1+_: This library enables authentication via Managed Service Identity, which avoids storing secrets in the source code or any associated configuration files.

[brentschmaltz]

@CBaud Great idea, I assigned this to the 5.2.4 milestone. Once we get going on that release, it would be great if you could help out with reviews and coding.

[brentschmaltz]

@CBaud we dropped 5.2.4 today (we had to skip a #), so 5.2.5 has started. If you are still interested in working on KV, let us know.

[CBaud]

Let's do it!

[brentschmaltz]

@CBaud how is this going?

[DaanWasscher]

Hi @CBaud,
With your PR I could successfully integrate with a KeyVault and sign/verify my jwt tokens. Thanks for that!

With the risk of going beyond the scope of your PR, I am wondering about a few things.
1) The full key vault uri is visible in the jwt header. Would that not come with a security risk (opening up a potential "attack vector")?
2) Has there been any thought on key rotation? It would be great if I could specify a key id without a specific version which would still work to verify jwt tokens that have been signed with the previous key version.
3) Verification has to go through the Key Vault which adds time to each request. Could the public key(s) be retrieved and cached somewhere so my application does not have to hit the Key Vault on each request?

[CBaud]

Hey @DaanWasscher,
I appreciate you taking the time to try out this new extension library. Thanks!

You've raised some interesting concerns, so let me take a moment to address them:

1. This is a valid security concern typically described as information disclosure. I believe this concern is mitigated by the fact that web requests to an Azure Key Vault resource are directed using HTTPS and require an Azure Active Directory access token for authorization. Reference
2. The currently library was implemented with the intent for the developer to use a specific version of a security key for their crypto operations. Expanding the implementation to accept a version-less security key and internally figure out the appropriate version to use is an interesting concept. If this is something you need, it would help for you to create a new issue so the team can evaluate and prioritize this work accordingly.
3. The JWT header should be sufficient for any authorized application to perform local verification instead of using Azure Key Vault. An authorized application can retrieve the public key from Azure Key Vault using the key identifier, and can use the algorithm specified in the header to determine the appropriate hashing algorithm to use. If you would like the extension library to provide this functionality, then please create a new issue so the team can evaluate and prioritize this work accordingly.

[brentschmaltz]

https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/pull/984

[mathiasbl]

Any examples/documentatie how to use this?