Summary Enterprise API integrations require more than simply obtaining an access token. The authentication model must provide a reliable way for an application to establish its identity while protecting the credentials used to do so. In this implementation, we explored a certificate-based authentication architecture using Microsoft Entra ID, an X.509 self-signed certificate, Azure Key Vault, Azure Functions, Managed Identity, and Microsoft Authentication Library (MSAL). The objective was to replace dependency on an expiring client secret with a certificate-backed application identity, while keeping the private certificate protected within Azure infrastructure. This article walks through the complete implementation — from creating the certificate and registering its public key, to storing the private certificate in Key Vault, configuring the Function App, and ultimately obtaining an OAuth 2.0 access token through MSAL. Table of Contents Introduction The Business Requirement Why Certificate-Based Authentication? Solution Overview The Authentication Architecture Step 1 — Creating the Microsoft Entra App Registration Step 2 — Creating the Self-Signed Certificate Step 3 — Exporting the Certificate Step 4 — Importing the Private Certificate into Azure Key Vault Step 5 — Registering the Public Certificate with Entra ID Step 6 — Creating the Azure Function Step 7 — Enabling Managed Identity Step 8 — Granting Key Vault Access Step 9 — Configuring Function App Settings Step 10 — Implementing Certificate Authentication with MSAL Step 11 — Obtaining the Access Token Understanding the Client Assertion Security and Production Considerations Key Implementation Lessons Frequently Asked Questions Conclusion Case Study Read more about our Journey with this Customer over here: View Case Study Introduction Enterprise applications increasingly depend on APIs to connect business processes across platforms. Microsoft Partner Center and other Microsoft services provide powerful APIs for automation, reporting, partner operations, customer processes, and broader Microsoft ecosystem integrations. As an integration moves toward production, however, authentication becomes an architectural concern rather than simply a configuration task. A client secret may be sufficient during initial development, but production integrations introduce additional questions: How should application credentials be protected? How should credentials be rotated? How can private credentials be kept outside application code? How can authentication be centralized for multiple consumers? How can the solution reduce dependency on manually managed secrets? These considerations led to a certificate-based authentication approach: Use a certificate-backed application identity, protect the private certificate in Azure Key Vault, and use an Azure Function with Managed Identity and MSAL to obtain the downstream access token. The implementation described in this article demonstrates that architecture from beginning to end using a self-signed certificate as the initial certificate credential. The Business Requirement The requirement was to establish an application-to-application authentication mechanism for Microsoft API integrations without relying on a long-lived client secret embedded across application components. The traditional client-secret model is straightforward: Application ↓ Client ID + Client Secret ↓ Microsoft Entra ID ↓ Access Token ↓ Target API The challenge is that the client secret behaves like a password. It must be securely stored, rotated, replaced before expiration, and carefully distributed to every application or service that needs it. The target architecture instead establishes application identity using a certificate: Application ↓ Certificate-backed application identity ↓ Microsoft Entra ID ↓ Access Token ↓ Target API Azure Key Vault then provides the security boundary for the private certificate material. Why Certificate-Based Authentication? Certificate authentication is based on asymmetric cryptography. The certificate contains a public key and corresponds to a private key. The public certificate can be registered with Microsoft Entra ID, while the private key remains protected by the application infrastructure. Microsoft Entra ID │ Public Certificate │ │ validates ▼ Azure Function ────── Signed Assertion │ │ └── Private Key protected by Azure Key Vault The important difference from a client secret is that the application proves possession of the private key rather than sending a reusable password-like credential as its application credential. Microsoft Authentication Library (MSAL) supports certificate credentials for confidential client applications. In MSAL.NET, the .WithCertificate() configuration allows MSAL to use the certificate to perform the client authentication process. Solution Overview End-to-end certificate-based authentication architecture The implementation separates authentication responsibilities across several Azure and Microsoft identity components. Component Responsibility Microsoft Entra App Registration Represents the application identity Public Certificate Registered with Entra ID to validate the application Private Certificate Used to prove possession of the registered certificate Azure Key Vault Protects the private certificate material Managed Identity Allows the Function App to access Key Vault without another secret Azure Function Centralizes token acquisition MSAL Handles the OAuth 2.0 client-credential authentication process Access Token Used to authorize requests against the target API The Authentication Architecture The complete authentication sequence can be simplified to: 1. Application calls the authentication Function ↓ 2. Function authenticates to Azure Key Vault using Managed Identity ↓ 3. Function retrieves the private certificate ↓ 4. MSAL loads the certificate ↓ 5. MSAL creates the signed client assertion ↓ 6. Assertion is sent to Microsoft Entra ID ↓ 7. Entra validates the certificate ↓ 8. Entra issues the access token ↓ 9. Function returns the access token ↓ 10. Consumer uses the token against the target API The key architectural separation is that the consumer does not need to manage the private certificate directly. The authentication layer manages certificate access and token acquisition. Step 1 — Creating the Microsoft Entra App Registration The first step is to create an App Registration representing the application that will authenticate with Microsoft Entra ID. For this implementation, the test application registration was: skenycerttestappreg The App Registration provides the application’s Client ID and Tenant ID and acts as the identity against which the certificate credential is registered. The App Registration stores the public certificate credential. It does not require the private key to be uploaded to Entra ID. Step 2 — Creating the Self-Signed Certificate For the initial implementation, a self-signed certificate was created locally using PowerShell. $cert = New-SelfSignedCertificate ` -Subject “CN=Test App Registration Certificate” ` -CertStoreLocation “Cert:\CurrentUser\My” ` -KeyExportPolicy Exportable ` -KeySpec Signature ` -KeyLength 2048 ` -NotAfter (Get-Date).AddYears(2) This creates a certificate … Continue reading From Client Secrets to Certificate-Based Authentication: Building a Secure Integration with Azure Key Vault and Azure Functions for a US based AI & Cyber Security Company →