In this article, I will walk you through everything you need to know about Azure App Registration. We will cover core identity concepts, step-by-step creation workflows, credential management, permission models, and security best practices.
Azure App Registration
What is an Azure App Registration?
At its core, an Azure App Registration is the mechanism that establishes a trust relationship between your custom application and the Microsoft identity platform. By registering your application in Microsoft Entra ID (formerly Azure Active Directory), you give Microsoft’s identity provider the necessary context to authenticate users, issue OAuth 2.0 access tokens, and authorize calls to protected APIs like Microsoft Graph or custom backends.
When you register an application, Microsoft Entra ID creates two distinct objects in the tenant:
- Application Object: The global blueprint or definition of your application, containing its core configuration settings (such as application name, supported account types, and branding).
- Service Principal Object: The local representation (or instance) of the application within a specific tenant. It governs the actual permissions, access policies, and assignment of users/groups to the application in that specific directory.
Application Object vs. Service Principal
To clarify how these two identity components work together, consider their structural differences:
| Feature | Application Object | Service Principal Object |
| Scope | Global definition (lives in the home tenant). | Local instance (lives in every tenant where used). |
| Purpose | Defines the app’s metadata, redirect URIs, and scopes. | Controls runtime access, token issuance, and enterprise policies. |
| Multi-Tenancy | Single primary record maintained by the app owner. | Replicated in target directories when multi-tenant consent is granted. |
| Modification | Updated directly by the application developer/owner. | Managed by tenant administrators in the local directory. |
Supported Account Types and Tenant Scopes
When setting up your application, Microsoft Entra ID provides four primary account options:
- Single Tenant (
Accounts in this organizational directory only): Restricted strictly to users and guest accounts inside your specific Microsoft Entra tenant. This is the recommended choice for internal line-of-business (LOB) applications. - Multi-Tenant (
Accounts in any organizational directory): Allows users from any Microsoft Entra tenant (such as enterprise customers or partners) to authenticate. This option is ideal for commercial SaaS products. - Multi-Tenant + Personal Microsoft Accounts: Enables sign-ins from both enterprise Microsoft Entra accounts and consumer accounts (e.g.,
@outlook.com,@live.com,@xbox.com). - Personal Microsoft Accounts Only: Reserved exclusively for consumer-facing apps that do not interact with corporate Entra directories.
Choosing the Right Tenant Scope
| Account Type Choice | Intended Audience | Security Risk Level | Recommended Primary Use Case |
| Single Tenant | Internal employees & vetted guests | Low | Internal company tools, HR portals, finance dashboards |
| Multi-Tenant | Business customers across organizations | Medium | B2B SaaS solutions, vendor integration tools |
| Multi-Tenant + Personal | Broad enterprise & consumer base | High | Multi-purpose productivity tools, public utility utilities |
| Personal Only | General public / Consumer accounts | Low to Medium | Gaming apps, personal consumer utilities |
Core Components of an Azure App Registration
Understanding the key properties inside the Azure Portal is critical when setting up identity flows correctly. When I inspect an existing registration, these are the primary elements I review:
1. Identifiers
- Application (Client) ID: A unique GUID assigned by Microsoft Entra ID that identifies your application globally. You will pass this string in every OAuth 2.0 authorization request.
- Directory (Tenant) ID: A unique GUID representing your specific Entra directory. For single-tenant applications, this gua