Service Principals and Application Identities in Microsoft Entra ID (SC-300)
Why Are Service Principals and Application Identities Important?
In modern cloud environments, applications and automated services need to authenticate and access resources just like human users do. However, giving applications human credentials (like usernames and passwords) is insecure, unmanageable, and violates the principle of least privilege. Service principals and application identities solve this problem by providing a dedicated identity for applications, enabling secure, auditable, and controllable access to Azure and Microsoft 365 resources.
For the SC-300 exam, this topic is critical because identity administrators must understand how to manage workload identities to protect organizational resources, enforce governance, and ensure compliance.
What Are Application Identities and Service Principals?
To fully understand this topic, you need to distinguish between several related concepts:
1. Application Object (App Registration)
An application object is the global definition or blueprint of an application. It is created when you register an application in Microsoft Entra ID (formerly Azure AD). The application object exists in the home tenant (the tenant where it was registered) and defines:
- The application's name and branding
- Redirect URIs for authentication
- API permissions the app needs
- Certificates and secrets used for authentication
- App roles that can be assigned
There is only one application object per application, and it resides in the home tenant.
2. Service Principal
A service principal is the local representation of an application object in a specific tenant. Think of it as an instance of the application in a given tenant. When an application is used in a tenant (including the home tenant), a service principal is automatically created. The service principal is what actually gets permissions, role assignments, and policies applied to it.
There are three types of service principals:
- Application Service Principal: Created when an app registration is made or when a multi-tenant app is consented to in another tenant. This is the most common type.
- Managed Identity Service Principal: Created automatically when a managed identity is enabled for an Azure resource. Managed identities are a special type of service principal where Azure manages the credentials.
- Legacy Service Principal: Represents older apps created before modern app registrations existed.
3. Enterprise Application
In the Microsoft Entra admin center, the Enterprise Applications blade shows service principals. This is essentially a view of all service principals in your tenant, including those from third-party SaaS apps, Microsoft apps, and your own registered applications.
How Do Service Principals and Application Identities Work?
Registration and Instantiation Flow:
1. A developer registers an application in the home tenant → an application object is created.
2. A service principal is automatically created in the home tenant.
3. If the application is multi-tenant, when a user in another tenant consents to the app, a new service principal is created in that tenant.
4. Administrators can then assign permissions, roles, and policies to the service principal in each tenant independently.
Authentication Methods for Service Principals:
- Client Secrets: A password-like string generated in the app registration. The application presents its Application (Client) ID and the secret to obtain a token. Secrets have expiration dates and should be rotated regularly. This is considered less secure than certificates.
- Certificates: An X.509 certificate is uploaded to the app registration. The application uses the private key to sign an assertion and authenticate. This is the recommended method as it is more secure than client secrets.
- Federated Credentials: Allow workloads running in external identity providers (like GitHub Actions, Kubernetes, or other clouds) to access Azure resources without managing secrets or certificates. This uses workload identity federation.
Permissions and Consent:
Service principals can be granted two types of permissions:
- Delegated Permissions: The application acts on behalf of a signed-in user. The effective permissions are the intersection of the app's permissions and the user's permissions.
- Application Permissions: The application acts as itself (no signed-in user). These are typically used for background services and daemons. Application permissions usually require admin consent.
Consent can be granted at two levels:
- User Consent: Individual users consent to delegated permissions (if allowed by policy).
- Admin Consent: A global administrator or a privileged role administrator grants consent on behalf of the entire organization. Required for application permissions and for sensitive delegated permissions.
Key Configuration Areas:
- API Permissions: Define what resources and scopes the application can access (e.g., Microsoft Graph, custom APIs).
- App Roles: Custom roles defined in the app registration that can be assigned to users, groups, or other service principals for app-level RBAC.
- Conditional Access for Workload Identities: Microsoft Entra ID supports Conditional Access policies targeting service principals (requires Workload Identities Premium license). You can restrict service principal sign-ins based on location or require specific conditions.
- Token Configuration: Customize claims included in the tokens issued to the application.
Governance and Security Considerations:
- Monitor service principal sign-in logs in Microsoft Entra ID to detect anomalous behavior.
- Use access reviews for service principals with Workload Identities Premium.
- Implement the principle of least privilege — grant only the permissions the application truly needs.
- Prefer certificates over client secrets for authentication.
- Set expiration policies on secrets and certificates, and rotate them before expiry.
- Restrict which users can register applications and consent to permissions using Entra ID settings.
- Use managed identities whenever possible to eliminate credential management entirely.
Relationship Summary:
- App Registration (Application Object) = Global blueprint (one per app, in home tenant)
- Service Principal = Local instance in a tenant (one per tenant where the app is used)
- Enterprise Application = The admin portal view of service principals
- Managed Identity = A special type of service principal with Azure-managed credentials
Exam Tips: Answering Questions on Service Principals and Application Identities
Tip 1: Know the Relationship Between App Registration and Service Principal
The exam frequently tests whether you understand that an app registration creates an application object, and a service principal is the local tenant instance. If a question asks how a multi-tenant app works in another tenant, the answer involves a service principal being created in the consuming tenant.
Tip 2: Understand Consent Models
Know when admin consent is required (application permissions, high-privilege delegated permissions) versus when user consent suffices. Questions may present scenarios where users cannot access an app — the likely cause is missing admin consent.
Tip 3: Certificates vs. Secrets
If a question asks for the most secure authentication method for a service principal, choose certificates over client secrets. If a question involves eliminating credential management, choose managed identities.
Tip 4: Delegated vs. Application Permissions
Delegated permissions = user is signed in, effective permissions are intersection of app and user permissions. Application permissions = no user context, app acts as itself. Daemon/background service scenarios always use application permissions.
Tip 5: Conditional Access for Workload Identities
Remember that Conditional Access can now target workload identities (service principals), but this requires Workload Identities Premium licensing. You can restrict by location but cannot require MFA for a service principal.
Tip 6: Managed Identities Are Preferred
Whenever a scenario involves an Azure resource (VM, App Service, Function App, etc.) needing to access another Azure resource (Key Vault, Storage, SQL), the best answer is almost always managed identity — specifically system-assigned for single-resource scenarios and user-assigned when sharing across resources.
Tip 7: Watch for Governance Scenarios
Questions about monitoring or reviewing application access often point to: service principal sign-in logs, access reviews for workload identities, or the enterprise applications blade for managing permissions and disabling unused apps.
Tip 8: Application Object Is in the Home Tenant Only
If you see a question about where to modify redirect URIs, API permissions, or upload certificates, the answer is always in the app registration in the home tenant. The service principal in other tenants inherits from the application object but is configured separately for assignments and policies.
Tip 9: Know How to Restrict App Registrations
Entra ID has a setting called Users can register applications. When set to No, only users with specific roles (Application Administrator, Cloud Application Administrator, or Global Administrator) can create app registrations. This is a common exam scenario.
Tip 10: Read Scenarios Carefully
Many questions will describe a business need (e.g., a background process that reads mailboxes) and ask which permission type and consent model to use. Map the scenario: no user interaction = application permissions = admin consent required. User-facing web app = delegated permissions = user or admin consent depending on the sensitivity.
