Why applications integrate with Microsoft Entra ID
Applications integrate with Microsoft Entra ID to offload identity and access management to a centralized, policy-driven identity provider. By registering applications, organizations can consistently control authentication, authorization, visibility, and governance across both cloud and on-premises workloads.
Applications are added to Microsoft Entra ID to consume one or more of the following services:
Application authentication and authorization.
User authentication and authorization.
Single sign-on using federation or passwords.
User provisioning and synchronization.
Role-based access control using application roles.
OAuth authorization services for APIs and protected resources.
Application publishing and proxy for private network access.
Directory schema extension attributes for storing additional identity data.
To support these capabilities, Microsoft Entra ID represents applications using two distinct but related objects: application objects and service principals.
Application objects
An application object defines the global identity and configuration of an application within Microsoft Entra ID. It tells the identity platform how tokens should be issued and what the application is allowed to request.
Managed in the App registrations experience.
Exist only in the home tenant, even for multitenant apps.
Define the application’s authentication and authorization model.
Application name, logo, and publisher.
Redirect URIs.
Secrets and certificates.
OAuth API dependencies.
Published APIs and scopes.
Application roles.
SSO configuration metadata.
User provisioning configuration.
Application Proxy configuration.
Manual app registration in the Azure portal.
Application creation in Visual Studio.
Adding apps from the gallery.
Microsoft Graph API or PowerShell.
Developer tooling and API explorers.
Service principals
A service principal represents the local instance of an application in a tenant. It governs how the application behaves inside that tenant.
Managed through Enterprise applications.
Created automatically when an app is first used in a tenant.
Enforces tenant-specific access, policies, and permissions.
A reference to the application object via the Application ID.
User and group role assignments.
Delegated and application permission grants.
Conditional Access policy assignments.
Tenant-specific configuration and branding.
Claims transformation rules.
Provisioning attribute mappings.
A user consents to an application.
Microsoft 365 services are enabled.
An admin adds an app from the gallery.
An app is published using Application Proxy.
An app is connected for SAML or password SSO.
Apps are created programmatically.
Relationship between application objects and service principals
One application object in its home tenant.
One service principal per tenant where it operates.
Microsoft-owned apps.
Pre-integrated third-party gallery apps.
Your organization’s applications follow the same model.
Important notes and exceptions
Not all service principals reference an application object. Early versions of Microsoft Entra ID allowed service principals to exist independently.
PowerShell can create service principals without application objects.
Microsoft Graph requires an application object first.
Claims transformation rules.
Provisioning attribute mappings.
Who can add applications
All users can register application objects.
All users can consent to apps for their own data.
This design enables developer self-service but must be governed carefully.
Reduced administrative overhead.
Improved visibility into app usage.
Automatic access revocation when users leave.
Full auditability of consent.
Granular permission control by API owners.
Restricting registration and consent
Go to Enterprise applications → User settings.
Set Users can consent to apps accessing company data to No.
Go to Microsoft Entra ID → User settings.
Set Users can register applications to No.
If user consent is disabled, administrators must approve all new apps.
Tenancy in Microsoft Entra ID
Microsoft Entra ID organizes users and applications into tenants, which act as security and policy boundaries. Tenants allow administrators to enforce policies consistently across users and apps.
Who can access your app (CRITICAL EXAM SECTION)
When registering an application, developers must choose who can sign in by configuring the application’s audience.
Single-tenant.
Multitenant.
Audience configuration options
| Audience setting | Tenant type | Who can sign in |
|---|---|---|
| Accounts in this directory only | Single tenant | All user and guest accounts in your tenant. Use for internal apps. |
| Accounts in any Microsoft Entra directory | Multitenant | Work or school accounts from any Entra tenant. |
| Accounts in any Entra directory and personal Microsoft accounts | Multitenant | Work, school, and personal Microsoft accounts (Outlook, Xbox, Skype). |
Best practices for multitenant apps
Multitenant apps must function in environments with unknown policies.
Testing against tenants with Conditional Access.
Requesting the minimum permissions required.
Using clear permission names and descriptions.
Expecting consent restrictions in customer tenants.