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 or Azure AD B2C by 3 means:
- client secrets
- client certificates
- client assertions
In addition to Client secrets, Microsoft.Identity.Web supports specifying client certificates in different ways. See Specifying certificates
You can describe the certificates to load, either by configuration, or programmatically
- 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 and optionally a password (probably only for debugging locally)
- directly from a base64 representation of the certificate
- from Azure KeyVault.
- directly providing it (programmatically only)
Describing the certificate by configuration allows for just in time loading, 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 your certificate is in KeyVault, Microsoft.Identity.Web leverages Managed identity, therefore enabling your application to have the same code when deployed (for instance on a VM or Azure app services), or locally on your developer box (using developer credentials)