Azure App Registration for using a Certificate for Authentication

This post explains how to create an Azure App Registration that will be used by applications that will authenticate using a digital certificate.

To use a certificate for authentication with Microsoft Graph (or any other service that supports OAuth2 client credentials flow with certificates), you typically follow the App-Only Authentication method. This method is used when you’re performing tasks as an application (rather than on behalf of a user) and is commonly used for automation, background services, or scripts that interact with Microsoft 365 or Azure services.

Here’s how you can authenticate using a certificate:

Prerequisites:

1. Azure App Registration: You need to have an application registered in Azure Active Directory (Azure AD).
2. Certificate: You must have a certificate available. This certificate will be used for authentication in place of a client secret.

Step-by-Step Guide to Authenticate Using a Certificate

1. Register an Application in Azure AD:

1. Go to the Azure Portal at [https://portal.azure.com](https://portal.azure.com) and sign in with your admin account.
2. Navigate to Microsoft Entra ID > App registrations > New registration.
3. Provide a name for your application and select the supported account types.  (see below)
4. There is no need to specify a Redirect URI. Leave it empty.
5. Click Register.

2. Upload the Certificate to the Azure AD Application:

1. In your app registration, go to the Certificates & Secrets section.
2. Under Certificates, click Upload certificate.
3. Upload your public certificate file (e.g., “.cer” or “.pem” file).
   • The private key for the certificate should be stored securely on your local machine (as a “.pfx” file or in the certificate store, or in a USB token).
4. Save the changes.

3. Assign API Permissions:

1. In the Azure AD app registration, go to API Permissions.
2. Click Add a permission.
3. Select Microsoft Graph > Application permissions.
4. Add the required permissions (e.g., “User.Read.All”, “Mail.Read”, etc.).
5. Grant admin consent for the permissions you added.

---

Choosing an Account Type

When creating an Azure App Registration for certificate-based authentication, the choice of account type depends on where and how the application will be used. Here are the options and their typical use cases:

Account Type Options:

1. Single Tenant:
   • Description: The app will only be available within your organization’s Azure Active Directory tenant.
   • Use Case: Choose this if the application is internal and will only be used by users, services, or applications within your own organization (one Azure AD tenant).
   • Typical Scenario: Internal automation scripts, services, or applications that access Microsoft 365 resources within your organization using certificate-based authentication.
2. Multitenant:
   • Description: The app can be used by any Azure Active Directory tenant, allowing it to authenticate users from multiple organizations.
   • Use Case: Choose this if your app will be used by users, services, or applications across multiple organizations. This is useful if your application is designed to be a SaaS (Software as a Service) product or needs to work with multiple Microsoft 365 tenants.
   • Typical Scenario: A third-party application that is offered to different organizations (tenants) or multiple customers who each have their own Azure AD tenant.
3. Accounts in Any Organizational Directory and Personal Microsoft Accounts:
   • Description: The app can be used by both organizational accounts (Azure AD accounts) and personal Microsoft accounts (such as Hotmail, Outlook.com).
   • Use Case: Choose this if the app needs to authenticate users from both Azure AD organizations and personal Microsoft accounts (e.g., consumer-facing applications).
   • Typical Scenario: Public-facing applications that provide services to both businesses (using Azure AD) and individual consumers (using personal Microsoft accounts).
4. Accounts in Any Organizational Directory Only:
   • Description: The app can authenticate Azure AD users from any organization (multitenant), but does not allow personal Microsoft accounts.
   • Use Case: This is a good choice if you want to make your app available to multiple Azure AD organizations but want to restrict access to only organizational accounts.
   • Typical Scenario: SaaS applications or multi-tenant applications that are intended for business users only and should not be accessible to users with personal Microsoft accounts.

Choosing the Right Option for Certificate-Based Authentication:

• For Internal Use (Single Organization): If you are creating an app registration to use certificate-based authentication within your own organization, choose Single Tenant. This will ensure that the app is only available to your organization’s users and services. For instance, if you’re building an internal tool that accesses Microsoft 365 resources for automation or integration, this is the most appropriate choice.
• For Multi-Organization Use (External Clients): If you are building an app that needs to be accessed by multiple organizations, such as a SaaS offering or a tool that different companies will use, choose Multitenant or Accounts in any organizational directory. This allows the app to be used by users and services from different Azure AD tenants.

Example Scenarios for Certificate-Based Authentication:

1. Single Tenant (Internal App):
   • An internal tool that automates Microsoft 365 tasks (e.g., reading mailboxes, managing users) for your organization.
   • A background service that runs in your own infrastructure, accessing your company’s Azure resources.
2. Multitenant (SaaS App):
   • A third-party service that offers Microsoft 365 integration for many companies, allowing them to manage calendars, send emails, or work with OneDrive.
   • A cloud-based service that integrates with Microsoft Graph for customers across different organizations.