Microsoft Entra ID Application Registrations

Why Application Registration Matters in Entra ID

Application registration is the foundational step for developers and IT professionals integrating applications with Microsoft Entra ID. Getting registration and permissions right ensures secure authentication, reliable authorization, and facilitates seamless interaction with Microsoft APIs, like Microsoft Graph. Missteps during registration can introduce significant security and operational risks, including excessive privilege, exposed secrets, or broken integrations. Whether you are building cloud-native applications, integrating legacy systems, or managing software as an identity engineer, understanding Entra ID application registration is fundamental to controlling how apps authenticate, what they can access, and how they are governed at scale.

Consider a scenario: You’re deploying a web app for your organization that needs to read user profiles from Microsoft Graph. Without a proper application registration, the app cannot authenticate against Entra ID or request API permissions, and misconfigured permissions can expose sensitive data or disrupt user consent flows. Precision here makes the difference between secure, maintainable integrations and long-term directory headaches.

Defining Entra ID Application Registration: Core Concepts

An Entra ID application registration is the process of recording an application's identity with Microsoft’s directory platform. The core byproduct of this process is the application object, a directory entry that acts as the authoritative ‘blueprint’ for your application.

This blueprint contains the immutable identity and configuration metadata for the app: its display name, redirect URIs (for OAuth 2.0/OpenID Connect callbacks), required permissions, supported account types (single-tenant or multi-tenant), and more.

Crucially, registration is not just about assigning a client ID and secret. It cryptographically anchors the app’s trust relationship with Entra ID, enabling the creation of service principals, managing permission scopes, and supporting robust security controls. Without registration, there is no sanctioned identity or managed consent model, and no way to hold the app accountable via policies or audit.

Key takeaway: The application object—a result of registration—is the authoritative template for your app’s identity and capabilities in Entra ID.

How Application Registration Relates to Service Principals and Enterprise Applications

The greatest source of confusion in the Microsoft identity ecosystem is the difference between app registration (application object) and enterprise application (service principal).

• Application Object: Created once, in the “home” tenant, during app registration. Defines what the app is: metadata, permissions, authentication settings. Think of it as a class or template.
• Service Principal (Enterprise Application): Instantiated in a tenant to represent that app for directory/resource access, with tenant-specific configuration and permissions. Think of it as an object or concrete instance, inheriting from the app registration template.

When you register an app, Entra ID creates the application object in your tenant. If your app is used by other tenants (multi-tenant app or SaaS scenario), a service principal is automatically created in each tenant where the app is assigned or consented to. The service principal—visible under “Enterprise Applications” in the portal—controls what the app can do in a particular tenant, such as which roles it is assigned and which permissions are granted.

Why does this distinction matter? Security policies, conditional access, consent, and role assignments are all enforced at the service principal level, not the global application object. For example, an app registration you control might have identical service principals in hundreds of customer tenants, but each can be configured or consented differently based on local security needs.

Example: A multi-tenant SaaS application: There’s a single application object in the ISV’s tenant. Each customer who connects their Entra ID creates a new service principal in their tenant, granting the app access to their resources according to their policies.

Step-by-Step: Registering an App in Entra ID

To register an application in Entra ID:

1. Sign in to the Microsoft Entra admin center.
2. Navigate to “App registrations,” select “New registration.”
3. Specify the name of the app. This name appears in consent prompts and in the directory.
4. Choose Supported Account Types:
   • Single-tenant (only users in your tenant can sign in)
   • Multi-tenant (users in any Entra tenant can sign in)
   • Accounts in any identity provider (for certain cross-cloud scenarios)
5. Configure Redirect URIs (for web, SPA, mobile, daemon/service applications) to specify the endpoint where authentication responses are sent.
6. Complete the registration. The portal generates the application object and assigns an Application (client) ID.

At this point, you can further configure authentication (certificates/secrets), API permissions, branding, and optional claims. Pay particular attention to:

• Naming: Make the display name clear but non-sensitive; it appears in user consent dialogs.
• Redirect URIs: Only allow exact URIs you control; avoid wildcards to reduce phishing risk.
• Supported account types: Select based on your app’s real audience; never open multi-tenancy by default.
• Credentials: Prefer certificates for app authentication. Only use client secrets for limited scenarios, and never in production when alternatives exist.

Example: You register a web application that needs to allow only your organization’s users. You’d choose “single-tenant,” specify the redirect URI (e.g., https://yourapp.com/auth/callback), and only request the permissions required for your use case.

Understanding and Managing Permissions: Delegated vs. Application, Consent Flow

Entra ID provides a granular permissions model to restrict how applications access APIs and directory data.

• Delegated Permissions: Allow the app to act on behalf of a signed-in user. The app cannot exceed the privileges of the user. Consent can typically be granted by users, unless tenant policy requires admin consent.
  • Example: The User.Read permission allows the app to read the profile of the current user; user or admin consent may suffice.
• Application Permissions: Grant the app permission to act without user context—suitable for background services, daemons, bulk data processors. Only administrators can consent to application permissions because there is no user involvement.
  • Example: The Directory.Read.All application permission allows full directory read access at all times; admin consent is mandatory.

Consent Flows:

• User Consent: Permitted for low-impact delegated permissions, unless blocked by policy.
• Admin Consent: Required for application permissions and for any delegated permission the admin has configured to restrict.

Consent mistakes often cause:

• Over-provisioning (granting excessive permissions to an app)
• Failed logins (required permissions not consented)
• Inability to scale (requiring all users to grant consent when admin consent would be more strategic)

Best practice: Always request the minimum permissions required and use admin consent only for high-privilege scenarios, ensuring tenant administrators are aware.

Securing App Registrations: Essential Best Practices

Registration security is not just about keeping track of client secrets. Every registration must be secured against abuse, privilege escalation, and compromise:

• Credential Hygiene:
  • Favor certificates over client secrets for authentication—client secrets are easier to leak and harder to rotate securely.
  • If running code in Azure (e.g., Azure Functions, App Service), prefer managed identities—they avoid static credentials entirely.
• Least Privilege: Only request permissions the app absolutely must have now. Review and remove unused permissions rigorously.
• Ownership & Delegation: Assign clear, minimal app owners. Only authorized, technical staff should own/modify critical app registrations.
• Registration Control: Restrict who in your tenant can create new app registrations. Unrestricted registration can lead to shadow IT and ungovernable risk.
• Redirect URI Discipline: Specify only URIs you control—never use wildcards or development endpoints in production.
• Monitor and Review: Regularly inventory app registrations and enterprise applications, audit what permissions have been consented, and remove or remediate as required.

Example: In production, you use a certificate or managed identity—not a client secret—as the app credential. Only security administrators may register new apps, and all existing registrations are regularly reviewed for stale permissions or excessive privilege.

Common Misconceptions and How to Avoid Critical Errors

• Misconception: App registration and enterprise application are interchangeable terms.
  Reality: The app registration creates an application object (the definition). The enterprise application refers to the service principal in a specific tenant (the instance)—they manage permissions and access locally.
• Misconception: All permissions can be granted via user consent.
  Reality: Many permissions (especially application permissions) require admin consent. User consent is limited and governed by tenant policies.
• Misconception: Client secrets are secure for production credentials.
  Reality: Client secrets are high risk in production. Use certificates, managed identities, or federated credentials wherever possible.
• Misconception: You can easily migrate or copy app registrations between tenants.
  Reality: Registrations are tenant-bound. Migration requires re-registration in the new tenant—a simple export/import does not exist.

Avoiding these errors is essential for both security and operational soundness.

Real-World Practical Examples

1. Web App for Internal Users:

   • Register app as single-tenant.
   • Assign only delegated User.Read permission.
   • Use certificate-based credential.
   • Admin consent granted once for all users.

2. SaaS Multi-Tenant App:

   • Register app in ISV’s home tenant (application object).
   • Customers connect, creating service principals (enterprise applications) in their own tenants.
   • Permissions and consent controlled per customer, enabling adherence to local security policies.

3. Background Service Script:

   • Register daemon app.
   • Assign only necessary application permissions (e.g., Directory.Read.All).
   • Require admin consent.
   • Use managed identity if app runs on Azure infrastructure.

Further Resources

Entra ID application registration underpins secure, audited identity integration in Microsoft’s ecosystem. Understanding the distinction between app registration and enterprise applications, carefully configuring and securing registrations, and rigorously managing permissions are the pillars of a safe and robust implementation. For comprehensive and up-to-date technical reference, always consult the latest Microsoft documentation on application registration, permissions, and security best practices before going to production.

Sources:

• Learn Microsoft Entra ID: Application Registration Quickstart
• Apps & Service Principals in Microsoft Entra ID
• Register and Create Service Principals in Microsoft Entra ID
• App Registration vs Enterprise Applications – Microsoft Q&A
• Security Best Practices for Application Properties
• Permissions and Consent Overview in Microsoft Identity Platform

Sources

• learn.microsoft.com — quickstart-register-app
• learn.microsoft.com — app-objects-and-service-principals
• learn.microsoft.com — howto-create-service-principal-portal
• learn.microsoft.com — security-best-practices-for-app-registration
• learn.microsoft.com — permissions-consent-overview
• learn.microsoft.com — app-registration-vs-enterprise-applications