This chapter covers app registrations and service principals in Azure Active Directory, including their creation, configuration, and relationship. Understanding these concepts is critical for the AZ-104 exam, as they underpin identity and access management for Azure resources, especially in automation and application scenarios. Approximately 15-20% of exam questions in the Identity Governance domain touch on app registrations, service principals, or related authentication flows.
Jump to a section
Think of an Azure AD tenant as a secure corporate headquarters building. An app registration is like an employee badge issued to a specific person (the app) who needs to enter the building. The badge has a unique ID (Application ID or client ID) and a photo (the app's logo or name). To get a badge, HR (Azure AD) creates a record in the system. But the badge alone doesn't grant access to all areas—it needs permissions. The service principal is the actual badge reader at the door. When the employee swipes their badge at a specific door (a resource like a storage account or VM), the reader checks the badge's identity and the permissions assigned to that badge for that door. In Azure, the app registration is the global identity definition (stored in the home tenant), while the service principal is the local representation (created in each tenant where the app needs access). Multiple service principals can be created from one app registration, just like the same employee badge can be programmed to open doors in multiple buildings, each with its own access rules. The client secret or certificate is like the PIN or biometric that proves the badge is being used by the right person. Without the secret, the badge is just a piece of plastic—it can't authenticate. This separation allows centralized app management with decentralized access control.
What Are App Registrations and Service Principals?
In Azure AD, an app registration is a global identity object that represents an application. Think of it as the application's blueprint or definition. It contains metadata such as the application name, redirect URIs, supported account types, and API permissions. The app registration is created in the home tenant of the application developer or owner.
A service principal is the local representation of an application in a specific tenant. It is the actual security principal that can be assigned roles and permissions to access Azure resources. When an app registration is created, a corresponding service principal is automatically created in the home tenant. If the application needs to access resources in other tenants (multi-tenant scenario), a service principal must be created in each target tenant, typically through admin consent.
Why Two Objects?
Azure AD separates the application definition (app registration) from its runtime identity (service principal) for several reasons: - Centralized management: The app registration can be updated once, and all service principals derived from it (in other tenants) remain linked. - Multi-tenant isolation: Each tenant has its own service principal, allowing independent permissions and consent. - Security: The app registration holds secrets and certificates, but the service principal is what actually authenticates. This separation allows auditing and permissions to be managed per tenant.
Creating an App Registration
To create an app registration in the Azure portal:
1. Navigate to Azure Active Directory > App registrations > New registration.
2. Provide a name (e.g., "MyAutomationApp").
3. Choose supported account types:
- Accounts in this organizational directory only (Single tenant): Only users in the same tenant can authenticate.
- Accounts in any organizational directory (Any Azure AD directory - Multitenant): Users from any Azure AD tenant can authenticate.
- Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts (e.g., Skype, Xbox): Broadest scope.
- Personal Microsoft accounts only: For consumer-facing apps.
4. Specify a redirect URI (optional but required for OAuth flows). For example, https://localhost:5000 for development.
After creation, note the Application (client) ID — this is the unique identifier for the app registration, used in authentication requests. The Directory (tenant) ID is also important, as it identifies the home tenant.
Creating a Service Principal
A service principal is created automatically when you register an app in a tenant. However, you can also create a service principal explicitly using PowerShell or Azure CLI:
# PowerShell
New-AzADServicePrincipal -DisplayName "MyServicePrincipal" -ApplicationId <client-id># Azure CLI
az ad sp create --id <client-id>If you omit the -ApplicationId or --id, a new app registration is also created. For existing app registrations, use the Application ID.
Authentication Methods
Service principals authenticate using one of the following: - Client secret: A string value generated by Azure AD. It has a start date and end date (max 2 years or custom). Secrets are sensitive and should be rotated regularly. - Certificate: An X.509 certificate uploaded to the app registration. The service principal uses the certificate's private key to sign authentication requests. Certificates are more secure than secrets and are recommended for production. - Federated identity credentials: Used in workload identity federation (e.g., with GitHub Actions or Kubernetes). No secret or certificate is stored in Azure AD.
Permissions and Consent
An app registration declares the permissions it needs via API permissions. These can be: - Delegated permissions: The app acts on behalf of a signed-in user. The user must consent, or an admin can grant consent for all users. - Application permissions: The app runs as a background service (daemon) without a user. These always require admin consent.
Permissions are defined in the app registration but are granted to the service principal through consent. When an admin grants consent, the service principal is assigned the requested permissions. For application permissions, this is equivalent to assigning the app a role.
Role Assignments for Service Principals
To access Azure resources (e.g., read blobs from a storage account), the service principal must be assigned an Azure RBAC role at the appropriate scope. This is done via:
New-AzRoleAssignment -ObjectId <service-principal-object-id> -RoleDefinitionName "Reader" -Scope "/subscriptions/<sub-id>/resourceGroups/<rg-name>"az role assignment create --assignee <service-principal-object-id> --role "Reader" --scope "/subscriptions/<sub-id>/resourceGroups/<rg-name>"The Object ID of the service principal (different from the Application ID) is used for role assignments.
Relationship Between Objects
App Registration: Has an Application ID (client ID) and is scoped to a single tenant (the home tenant). It can be multi-tenant if configured.
Service Principal: Has an Object ID and is created per tenant. A single app registration can have multiple service principals (one per tenant).
Enterprise Application: In the Azure portal, the "Enterprise applications" blade shows all service principals in the tenant, including those from app registrations, Microsoft apps, and gallery apps.
Default Values and Timers
Client secret maximum validity: 2 years (24 months) when created via portal; custom expiry can be set via PowerShell or CLI.
Certificate thumbprint: 40-character hex string.
Redirect URI: Must use HTTPS for production (except for localhost).
Token lifetime: Access tokens for Microsoft Graph or Azure Resource Manager typically last 60-90 minutes. Refresh tokens can last up to 90 days if not revoked.
Verification Commands
List all service principals in the tenant:
Get-AzADServicePrincipal | Format-Table DisplayName, Id, ApplicationIdaz ad sp list --output tableGet details of a specific service principal:
Get-AzADServicePrincipal -ObjectId <object-id>az ad sp show --id <object-id>Common Scenarios
Automation with Azure Automation: Create a Run As account (which creates a service principal) to authenticate runbooks.
CI/CD pipelines: Use a service principal in Azure DevOps or GitHub Actions to deploy resources.
Multi-tier applications: A web app (with a managed identity or service principal) accesses a database or storage account.
Exam Relevance
The AZ-104 exam expects you to:
Differentiate between app registrations and service principals.
Know how to create and manage service principals.
Understand the authentication methods (secret vs certificate).
Assign RBAC roles to service principals.
Troubleshoot common issues like expired secrets or insufficient permissions.
Register an Application
Navigate to Azure AD > App registrations > New registration. Provide a name, select supported account types (e.g., 'Accounts in this organizational directory only'), and optionally set a redirect URI. Click Register. The portal creates an app registration object with a unique Application (client) ID and Directory (tenant) ID. These IDs are used in authentication requests. The app registration is now the global identity for the application. It does not yet have permissions to access any resources.
Configure Authentication Methods
In the app registration blade, go to 'Certificates & secrets'. To create a client secret, click 'New client secret', provide a description, and choose an expiry (1 year, 2 years, or custom). The secret value is displayed only once; copy and store it securely. Alternatively, upload a certificate under 'Certificates'. The certificate must be in .cer, .pem, or .crt format. The thumbprint is calculated and stored. For production, certificates are preferred over secrets due to higher security and automatic rotation capabilities.
Grant API Permissions
Under 'API permissions', click 'Add a permission'. Select Microsoft Graph or another API. Choose delegated permissions (e.g., User.Read) or application permissions (e.g., User.Read.All). For application permissions, admin consent is required. Click 'Grant admin consent' to approve the permissions for the entire tenant. This step is critical because without consent, the service principal cannot use the permissions, even if assigned RBAC roles.
Assign RBAC Role to Service Principal
The service principal (automatically created in the same tenant) must be assigned an RBAC role to access Azure resources. Go to the subscription or resource group, select 'Access control (IAM)', click 'Add role assignment', choose a role (e.g., Contributor), and select the service principal by name or object ID. Alternatively, use PowerShell: New-AzRoleAssignment -ObjectId <sp-object-id> -RoleDefinitionName 'Reader' -Scope '/subscriptions/<sub-id>/resourceGroups/<rg>'. The service principal can now authenticate and perform actions based on the role.
Authenticate and Use the Service Principal
To authenticate, an application uses the client ID and secret (or certificate) to request an access token from Azure AD's token endpoint (https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token). The token is then presented to the target resource (e.g., Azure Resource Manager). The resource validates the token and checks if the service principal has the required RBAC role. If successful, the request is allowed. Common issues include expired secrets, incorrect tenant ID, or missing role assignments.
Enterprise Scenario 1: CI/CD Pipeline Deployment
A large enterprise uses Azure DevOps to deploy infrastructure to multiple Azure subscriptions. Instead of using personal credentials, they create a service principal for the pipeline. The DevOps team registers an app in the main tenant and creates a client secret. They assign the service principal the Contributor role on each target subscription. The pipeline uses the service principal's credentials (client ID and secret) stored as a secret variable in Azure DevOps to authenticate via Azure CLI or PowerShell. This ensures that deployments are automated, auditable, and not tied to any individual. Common issues: secret expiry causes pipeline failures, so they implement a rotation policy using Azure Key Vault and automation to renew the secret before it expires. They also use certificates for higher security, stored in Key Vault and referenced by the pipeline.
Scenario 2: Multi-Tenant SaaS Application
A software vendor builds a SaaS application that needs to read users' calendar data from their work or school accounts. They register the app as multi-tenant (Accounts in any organizational directory). When a customer tenant admin signs up, they are redirected to consent to the required permissions (e.g., Calendars.Read). This creates a service principal in the customer's tenant. The vendor's app then authenticates using its own credentials (client ID and secret from the home tenant) and uses the Microsoft Graph API to access data in the customer's tenant. The service principal in the customer tenant is assigned the necessary Graph permissions via admin consent. Misconfiguration: if the app requests application permissions that require admin consent but the customer admin does not grant it, the app fails silently. The vendor must handle consent responses gracefully.
Scenario 3: Azure Automation Runbooks
An IT operations team uses Azure Automation to run maintenance scripts (e.g., restart VMs, clean up disks). They create a Run As account, which automatically creates a service principal with Contributor rights on the subscription. The runbooks use the Connect-AzAccount -ServicePrincipal -Credential cmdlet with the service principal's credentials stored in the Automation account's encrypted variables. Over time, the service principal's secret expires, causing runbooks to fail. The team must monitor secret expiry and rotate it manually or use a certificate-based authentication. They can also use managed identities for Azure resources (which is a type of service principal automatically managed by Azure) to avoid secret management entirely.
AZ-104 Exam Focus on App Registrations and Service Principals
This topic falls under Domain 1: Identity Governance (15-20%) and Objective 1.1: Manage Azure Active Directory (Azure AD) objects. The exam specifically tests your ability to:
Create and manage service principals.
Differentiate between app registrations, service principals, and managed identities.
Assign RBAC roles to service principals.
Understand authentication methods (secrets vs certificates).
Troubleshoot authentication failures.
Common Wrong Answers and Traps
Confusing App Registration with Service Principal: A question might ask 'What object is created when you register an app?' The correct answer is 'App registration', but many candidates choose 'Service principal' because they think the service principal is created first. In reality, the service principal is created automatically but is a separate object. The exam may ask for the object that holds the client ID and secrets—that's the app registration.
Assuming Service Principals Have Permissions by Default: A question might describe a scenario where a service principal cannot access a storage account even though it has a role assignment. The likely issue is that the service principal lacks API permissions (e.g., Microsoft Graph permissions) or the role assignment is at the wrong scope. Candidates often forget that RBAC roles are separate from API permissions.
Misunderstanding Multi-Tenant Consent: A question might state that a multi-tenant app can access resources in another tenant without any configuration. The correct answer is that admin consent must be granted in the target tenant to create a service principal. Candidates may think consent is automatic.
Secret Expiry: The exam loves to test that client secrets have a maximum validity of 2 years and that you must rotate them. A question might ask 'How long can a client secret be valid?' with options including 'No expiry' or '5 years'. The correct answer is 2 years (or 24 months).
Specific Numbers and Terms
Application (client) ID: A GUID, e.g., 00000000-0000-0000-0000-000000000000.
Object ID: Another GUID for the service principal.
Tenant ID: GUID for the Azure AD tenant.
Client secret: Max 2 years validity.
Certificate thumbprint: 40 hex characters.
Redirect URI: Must be HTTPS except for localhost.
Consent: Required for delegated and application permissions.
Edge Cases
Managed Identity: A type of service principal that is automatically managed by Azure. It cannot have secrets or certificates; Azure rotates the credentials automatically. The exam may ask you to choose between a managed identity and a service principal for a scenario.
Service Principal Without App Registration: You can create a service principal directly using PowerShell (New-AzADServicePrincipal without an ApplicationId), which also creates an app registration. But you cannot have a service principal without an underlying app registration.
Deleted Service Principal: If you delete the service principal, the app registration remains. You can recreate the service principal by re-consenting or using PowerShell.
How to Eliminate Wrong Answers
If the question mentions 'client secret' or 'certificate', the answer involves an app registration or service principal.
If the question asks about 'automatic credential rotation', the answer is 'managed identity'.
If the question involves 'access to Azure resources', think about RBAC role assignment on the service principal.
If the question involves 'access to Microsoft Graph', think about API permissions and consent.
App registration is the global identity; service principal is the local instance in a tenant.
Service principals authenticate using client secrets (max 2 years) or certificates.
RBAC roles are assigned to service principals, not app registrations.
API permissions (delegated or application) require consent before use.
Managed identities are a type of service principal with automatic credential management.
Multi-tenant apps require admin consent in each tenant to create a service principal.
The Application (client) ID identifies the app registration; Object ID identifies the service principal.
These come up on the exam all the time. Here's how to tell them apart.
App Registration
Global identity object stored in home tenant.
Holds client ID, secrets, certificates, redirect URIs.
Defines API permissions and supported account types.
Cannot be assigned RBAC roles directly.
One app registration can have multiple service principals.
Service Principal
Local representation of app in a specific tenant.
Has an Object ID unique to the tenant.
Is the actual security principal for authentication.
Can be assigned RBAC roles to access Azure resources.
Created automatically when app is registered or consent is granted.
Mistake
App registration and service principal are the same object.
Correct
They are separate. App registration is the global identity definition; service principal is the local instance in a tenant. One app registration can have multiple service principals across tenants.
Mistake
A service principal can authenticate without any secret or certificate.
Correct
Service principals require a client secret, certificate, or federated credential to authenticate. Managed identities are the exception, as Azure handles credentials automatically.
Mistake
Assigning RBAC role to an app registration gives it access to resources.
Correct
RBAC roles must be assigned to the service principal (or managed identity), not the app registration. The app registration is just a definition; it cannot authenticate on its own.
Mistake
Client secrets have no expiry.
Correct
Client secrets have a maximum validity of 2 years (24 months). They must be rotated before expiry. Azure AD does not support non-expiring secrets.
Mistake
Multi-tenant apps automatically have access to all tenants.
Correct
Multi-tenant apps require admin consent in each target tenant to create a service principal. Without consent, the app cannot access resources in that tenant.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An app registration is the global application definition that contains metadata like client ID, secrets, and API permissions. A service principal is the local instance of that app in a specific Azure AD tenant, used for authentication and authorization. You assign RBAC roles to the service principal, not the app registration. The app registration can be multi-tenant, but each tenant has its own service principal.
When you register an app in a tenant, a service principal is automatically created in the same tenant. For other tenants, you must grant admin consent to create a service principal there. You can also use PowerShell: New-AzADServicePrincipal -ApplicationId <client-id>. This creates a service principal in the current tenant context.
The maximum validity for a client secret is 2 years (24 months) when created via the Azure portal. Using PowerShell or Azure CLI, you can set a custom expiry up to 2 years. Secrets cannot be set to never expire. For longer-lived credentials, use certificates or managed identities.
Yes, a service principal (via its app registration) can have multiple client secrets and certificates. This allows you to rotate secrets without downtime—you can add a new secret, update applications to use it, then remove the old one. The maximum number of secrets and certificates per app registration is 10 each.
You assign RBAC roles to the service principal just like to a user. In the Azure portal, go to the resource scope (subscription, resource group, etc.), select Access control (IAM), click Add role assignment, choose the role, and search for the service principal by name or object ID. Alternatively, use PowerShell: New-AzRoleAssignment -ObjectId <sp-object-id> -RoleDefinitionName 'Reader' -Scope '/subscriptions/<sub-id>'.
Both are identities used by applications to authenticate to Azure AD. A service principal is manually created and managed, requiring you to handle secrets or certificates. A managed identity is automatically created and managed by Azure; you cannot manage its credentials. Managed identities are tied to an Azure resource (like a VM or App Service) and are recommended for Azure-internal workloads to avoid credential management.
First, verify that the client ID, tenant ID, and secret/certificate are correct. Check if the secret has expired. Ensure the service principal has the required RBAC role assignment at the correct scope. If using Microsoft Graph, verify API permissions and consent. Use tools like `az login --service-principal -u <client-id> -p <secret> --tenant <tenant-id>` to test authentication. Check Azure AD sign-in logs for failure reasons.
You've just covered App Registrations and Service Principals — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?