Using certificates
Microsoft.Identity.Web uses certificates in two situations:
-
In web apps and web APIs, to prove the identity of the application, instead of using a client secret
-
In web APIs, to decrypt tokens in the web API opted to get encrypted tokens.
Web apps and Web APIs are confidential client applications.
They can prove their identity to Azure AD by 3 means:
- client secrets
- client certificates
- client assertions
Today, Microsoft.Identity.Web enables developers to provide client secrets. In addition to Client secret, we'd want Microsoft.Identity.Web to support client certificates. The constraints are the following:
- enable several ways of getting the certificate. You'd provide a description on how to get the certificate.
- from the certificate store (Windows) and a thumbprint ("440A5BE6C4BE2FF02A0ADBED1AAA43D6CF12E269")
- from the certificate store (Windows) and a distinguished name ("CN=TestCert")
- from a path on the disk (probably only for debugging locally)
- directly from a base64 representation of the certificate
- from a KeyVault address.
- getting the certificate just in time, rather than paying the startup cost. For instance for a web app that signs in a user, not load the certificate until an access token is needed to call a Web API.
- when the certificate is stored in KeyVault, leverage Managed identity (probably though the Azure SDK for .NET)
- help you rotating your certificates but letting you provide several (2) certificates