This chapter covers Azure App Registrations and Service Principals, the core identity objects for applications in Azure AD. For the AZ-500 exam, this topic appears in roughly 10-15% of questions under domain 1.3 (Manage Application Access). You will be tested on the differences between app registrations and service principals, how to configure permissions and consent, and how to manage certificates and secrets for authentication. Mastery of these concepts is essential for securing automated workloads and third-party integrations.
Jump to a section
An app registration is like a company issuing a badge to an employee. The employee (app) has a name (app ID) and a role (permissions). The badge (registration) proves the employee's identity to others. When the employee wants to enter a secure room (resource), they show their badge. The room's guard (Azure AD) checks the badge against a list of authorized employees (permissions). However, the badge itself doesn't grant access—the guard must verify the employee's identity each time. For automation, a service principal is like a service account—a non-human identity that has its own badge and can be granted specific access. For example, a script that reads blobs from a storage account uses a service principal with the 'Storage Blob Data Reader' role. The script authenticates using the service principal's credentials (client ID and secret/certificate) and gets a token, which it presents to the storage account. The storage account's guard checks the token and grants access based on the assigned role. This is different from a user's personal badge—the service principal has no human behind it, only automated tasks.
What Are App Registrations and Service Principals?
Azure AD uses a two-object model for application identities: the App Registration and the Service Principal. An app registration is the global, application-level definition that exists in a single Azure AD tenant (or multiple tenants if multi-tenant). It contains metadata such as redirect URIs, certificates, secrets, and API permissions. The service principal, on the other hand, is the local representation of that application in a specific tenant. It is the actual identity that gets assigned roles and permissions to access resources. Think of the app registration as the blueprint and the service principal as the actual building constructed from that blueprint.
For example, when you register an app in your tenant, Azure AD automatically creates a service principal object in that same tenant. If you configure the app for multi-tenant access, each tenant where the app is consented will get its own service principal object. The app registration remains in your tenant; the service principals are created in each tenant that uses the app.
How It Works Internally
When an application authenticates to Azure AD, it uses the OAuth 2.0 protocol. The flow involves these steps:
The app obtains credentials (client ID + client secret or certificate) from the app registration.
The app sends an authentication request to Azure AD's token endpoint (https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token).
Azure AD validates the credentials against the app registration. If valid, it issues an access token.
The token contains claims including the app ID (client ID), the service principal object ID, and the scopes/permissions the app has been granted.
The app presents this token to the target resource (e.g., Microsoft Graph, Azure Storage).
The resource validates the token and checks if the service principal has the required permissions (via role assignments or delegated permissions).
The key difference from user authentication: there is no interactive login. The app authenticates using its own credentials, not a user's. This is called client credentials grant flow.
Key Components, Values, and Defaults
Application (Client) ID: A globally unique identifier (GUID) for the app registration. This is the public identifier used in authentication requests.
Object ID: The unique identifier for the service principal within a tenant. This is used for role assignments.
Client Secret: A string value (up to 40 characters, configurable expiration up to 2 years) used as a password. Secrets are hashed and stored in the tenant. They can be rotated.
Certificate: An X.509 certificate (public key) that can be used instead of a secret. More secure because private key never leaves the app. The thumbprint is used for identification.
Redirect URIs: URLs where Azure AD sends authentication responses. Must be registered in the app registration. For web apps, typically https://localhost or https://yourapp.com. For native apps, can use custom schemes.
API Permissions: List of permissions (scopes) the app requests. These can be delegated (acting on behalf of a signed-in user) or application (acting as itself). Application permissions require admin consent.
Consent: The process of granting permissions to an app. For delegated permissions, a user can consent (if allowed). For application permissions, an admin must consent via the Azure portal or PowerShell.
Default Token Lifetime: Access tokens default to 60-90 minutes (configurable via Conditional Access or Microsoft Graph policies). Refresh tokens for delegated flows can last up to 90 days.
Configuration and Verification Commands
You can create an app registration and service principal using Azure CLI:
az ad app create --display-name "MyApp" --identifier-uris "https://myapp.contoso.com" --sign-in-audience AzureADMyOrg
az ad sp create --id <app-id>To list service principals:
az ad sp list --all --output tableTo assign a role to a service principal (e.g., Contributor on a resource group):
az role assignment create --assignee <service-principal-object-id> --role Contributor --resource-group MyRGTo authenticate using a service principal (non-interactive):
az login --service-principal -u <app-id> -p <client-secret> --tenant <tenant-id>Using PowerShell:
Connect-AzAccount -ServicePrincipal -Credential (New-Object System.Management.Automation.PSCredential ('<app-id>', (ConvertTo-SecureString '<client-secret>' -AsPlainText -Force))) -Tenant <tenant-id>Interaction with Related Technologies
Managed Identities: Azure automatically creates a service principal for Azure resources (VMs, App Services, etc.) and manages its credentials. This eliminates the need to store secrets in code. The service principal is created in the same tenant as the resource.
Conditional Access: Policies can target service principals (e.g., require multi-factor authentication for admin apps). Note: Conditional Access for service principals is in preview and limited to certain scenarios.
Microsoft Graph: To read/write directory data, the app must be granted Microsoft Graph permissions (e.g., User.Read.All). These are configured in the app registration.
Azure AD B2B: Guest users can consent to apps, creating service principals in their home tenant.
Azure AD Application Proxy: Publishes on-premises apps using a service principal that acts as a connector.
Best Practices
Use certificates instead of secrets for production workloads. Certificates have longer validity and cannot be easily leaked as plaintext.
Rotate secrets regularly (e.g., every 6 months). Use Azure Key Vault to store secrets and certificates.
Assign the least privileged roles to service principals. Use custom roles if needed.
Monitor sign-in logs for service principals (Azure AD > Sign-ins > Service principal sign-ins). Look for unusual locations or failed authentication.
Use managed identities when possible to avoid credential management altogether.
For multi-tenant apps, validate that the service principal is from a trusted tenant.
Troubleshooting
Common issues: - 401 Unauthorized: The token is invalid or expired. Check that the audience (aud claim) matches the resource. For example, a token for Microsoft Graph must have aud=https://graph.microsoft.com. - 403 Forbidden: The token is valid but the service principal lacks permissions. Check role assignments and API permissions. - AADSTS700016: Application with identifier was not found. Ensure the client ID and tenant ID are correct. - AADSTS7000218: The request body must contain the following parameter: 'client_assertion' or 'client_secret'. Missing credentials.
Use az rest or Postman to manually test token acquisition:
az account get-access-token --resource https://graph.microsoft.comFor service principal authentication, you can decode the token at jwt.ms to inspect claims.
Create App Registration
In the Azure portal, navigate to Azure Active Directory > App registrations > New registration. Provide a name (e.g., 'MyWebApp'), select supported account types (e.g., 'Accounts in this organizational directory only' for single tenant), and set a redirect URI (e.g., https://localhost:44321). Click Register. The app registration is created with an Application (client) ID (GUID) and an Object ID. This step defines the application's identity globally. The redirect URI is critical for OAuth flows—it must match exactly what the app sends. Azure AD will only send tokens to registered redirect URIs.
Create Service Principal
When you register an app, Azure AD automatically creates a service principal in the same tenant. You can verify this by going to Azure AD > Enterprise applications > All applications and searching for your app name. The service principal has an Object ID (different from the app registration's Object ID). This service principal is the identity that will be assigned roles. If you need a service principal without an app registration (e.g., for legacy apps), you can create one manually via PowerShell: New-AzADServicePrincipal. However, for modern apps, always use app registration.
Configure Authentication
In the app registration, go to Certificates & secrets. Add a client secret (recommend 24 months expiration for dev, 12 for prod) or upload a certificate. Also configure API permissions: add permissions for Microsoft Graph (e.g., User.Read.All as application permission) and then click 'Grant admin consent' (requires Global Admin or Privileged Role Admin). Without admin consent, the service principal cannot use application permissions. For delegated permissions, users can consent individually. Note: Granting admin consent is irreversible for that permission.
Assign Azure RBAC Role
To allow the service principal to access Azure resources (e.g., VMs, storage), assign an RBAC role at a scope (subscription, resource group, resource). In Azure portal, go to the resource, select Access control (IAM) > Add role assignment. Select a role (e.g., Contributor) and search for the service principal by name. Click Save. This creates a role assignment that links the service principal to the role. The service principal can now authenticate and perform actions within that scope. Note: This is separate from API permissions for Microsoft Graph.
Authenticate and Test
Use the service principal credentials to get an access token. Example using curl: curl -X POST -H 'Content-Type: application/x-www-form-urlencoded' -d 'client_id=<app-id>&client_secret=<secret>&grant_type=client_credentials&scope=https://graph.microsoft.com/.default' https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token. The response includes an access_token (JWT). Decode it at jwt.ms to verify claims: aud (audience), appid, oid (service principal object ID). Use the token to call the resource API (e.g., GET https://graph.microsoft.com/v1.0/users). If you get 403, check permissions. If 401, token may be expired or audience mismatch.
Enterprise Scenario 1: Automated Backup Script
A company runs a daily backup script on a virtual machine that copies files to Azure Blob Storage. The script needs to authenticate to Azure. Using a service principal: the DevOps team creates an app registration with a certificate (stored in Azure Key Vault). They assign the service principal the 'Storage Blob Data Contributor' role on the storage account. The script runs on a schedule, retrieves the certificate from Key Vault (using managed identity of the VM), and gets a token to access blob storage. This avoids storing any secrets in the script. Common issues: certificate expiration (must be monitored) and role scope too broad (e.g., contributor on all storage accounts instead of one). Best practice: use managed identity for the VM itself instead of a separate service principal, but if the script runs on-premises, a service principal is necessary.
Enterprise Scenario 2: Multi-Tenant SaaS Application
An ISV builds a SaaS app that reads users' calendar data via Microsoft Graph. They register the app in their own tenant as a multi-tenant app. When a customer tenant admin consents, a service principal is created in the customer tenant. The ISV's app uses the client credentials flow with its own secret to get a token for the customer tenant. However, the token's audience is the customer's tenant, so the app must use the customer's tenant-specific endpoint. The app must handle the case where consent is revoked or admin changes permissions. Also, the ISV must ensure the app only requests necessary permissions (e.g., Calendars.Read) and not over-privileged ones like Directory.Read.All. Misconfiguration: not using the correct tenant ID in the token request leads to AADSTS700016. Also, if the app is deleted from the ISV tenant, all service principals are automatically removed from customer tenants.
Enterprise Scenario 3: CI/CD Pipeline Deployment
A development team uses Azure DevOps to deploy infrastructure using Terraform. The pipeline uses a service principal to authenticate to Azure. The service principal is assigned 'Contributor' at the subscription level. However, this is too broad—a malicious pipeline change could delete all resources. Better: assign specific roles at resource group level or use custom roles with least privilege. Also, the service principal's credentials (secret) are stored as a variable group in Azure DevOps. If the secret leaks, an attacker could deploy resources. Mitigation: use federated identity (OIDC) between Azure DevOps and Azure AD, which eliminates static secrets. The service principal still exists but uses token exchange instead of a secret. This is a growing trend in enterprise CI/CD.
AZ-500 Exam Focus: App Registrations and Service Principals
This topic falls under Domain 1: Manage Identity and Access (30-35% of exam) and specifically Objective 1.3: Manage application access (about 10-15% of exam questions). The exam tests your ability to:
Differentiate between app registrations and service principals.
Configure authentication: secrets vs. certificates, redirect URIs, supported account types.
Manage permissions: delegated vs. application permissions, consent (user vs. admin).
Assign RBAC roles to service principals.
Troubleshoot common authentication errors.
Most Common Wrong Answers
'App registration and service principal are the same object.' – Many candidates think they are interchangeable. The exam may present a scenario where you need to assign a role to 'the app' – the correct answer is to use the service principal (object ID), not the app registration (client ID). The wrong answer often uses the app registration's object ID.
'Application permissions require user consent.' – Application permissions always require admin consent. Delegated permissions can be consented by users (if allowed). The exam may ask: 'An app needs to read all users' profiles without a signed-in user. Which permission type and consent is needed?' Correct: Application permission + admin consent. Wrong: Delegated permission + user consent.
'Client secret is the most secure authentication method.' – Certificates are more secure. The exam may present a scenario where an app is moving to production and ask which credential type to use. Wrong answer: client secret (because it's easier). Correct: certificate (because private key is never shared).
'Managed identities are a type of service principal.' – While technically a managed identity creates a service principal, the exam treats them as separate concepts. Managed identities are for Azure resources only; service principals are for external apps. The question might ask: 'Which identity type should you use for an on-premises application?' Correct: service principal. Wrong: managed identity (because it's only for Azure resources).
Specific Numbers and Terms
The default token lifetime for access tokens is 60 minutes (configurable). Refresh tokens default to 90 days for single-page apps, 14 days for native apps.
Client secrets can have a maximum lifetime of 2 years (24 months).
The maximum number of secrets per app registration is 10.
The OAuth 2.0 client credentials grant is used for non-interactive authentication.
The /.default scope is used to request all application permissions the app has been granted.
Admin consent endpoint: https://login.microsoftonline.com/{tenant-id}/adminconsent
Edge Cases
Guest users and service principals: A guest user can consent to an app, creating a service principal in the guest's home tenant. This is tested in B2B scenarios.
Service principal sign-in logs: Located under Azure AD > Sign-ins > Service principal sign-ins (not under Users).
Conditional Access for service principals: In preview, limited to blocking or requiring MFA for specific apps.
App roles vs. Azure RBAC: App roles are defined in the app registration and assigned to users/groups. Azure RBAC is for Azure resources. The exam may mix these up.
How to Eliminate Wrong Answers
If the question mentions 'on behalf of a user' → delegated permissions.
If the question mentions 'no user interaction' → application permissions.
If the question mentions 'assigning a role to an app' → use the service principal object ID.
If the question mentions 'storing credentials securely' → Azure Key Vault.
If the question mentions 'automatically managed credentials' → managed identity.
Always check the audience: tokens for Microsoft Graph have aud=https://graph.microsoft.com; tokens for Azure Resource Manager have aud=https://management.azure.com.
An app registration is the blueprint; a service principal is the actual identity used for authentication and authorization.
Use certificates instead of client secrets for production workloads to reduce risk of credential exposure.
Application permissions require admin consent; delegated permissions can be consented by users (if allowed).
Assign RBAC roles to the service principal (using its Object ID), not the app registration.
Managed identities are a type of service principal with automatic credential management, but only for Azure resources.
The client credentials grant flow (OAuth 2.0) is used for non-interactive authentication by service principals.
The /.default scope requests all application permissions the app has been granted.
Default access token lifetime is 60 minutes; refresh token lifetime varies (up to 90 days).
These come up on the exam all the time. Here's how to tell them apart.
App Registration
Global application definition in one tenant.
Has Application (client) ID and Object ID.
Contains metadata: redirect URIs, secrets, certificates, API permissions.
Cannot be assigned Azure RBAC roles directly.
Exists only in the tenant where it was created.
Service Principal
Local instance of an app in a specific tenant.
Has its own Object ID (different from app registration).
Is the identity that gets permissions and roles.
Can be assigned Azure RBAC roles.
Exists in each tenant where the app is used.
Mistake
An app registration and a service principal are the same thing.
Correct
An app registration is the global application definition; a service principal is the local instance in a tenant. They have different object IDs. The app registration exists in the tenant where it was created; the service principal exists in each tenant where the app is used.
Mistake
Client secrets are more secure than certificates.
Correct
Certificates are more secure because the private key never leaves the application. Secrets are stored as plaintext in Azure AD and can be leaked if the app is compromised. Certificates also support automatic rotation via Key Vault.
Mistake
Application permissions can be consented by a regular user.
Correct
Application permissions always require admin consent because they grant the app access to all data in the organization, not just a user's data. Only a Global Admin or Privileged Role Admin can grant admin consent.
Mistake
Managed identities are not service principals.
Correct
Managed identities are a special type of service principal that is created and managed by Azure. They are service principals with automatic credential management. However, they are limited to Azure resources and cannot be used for external applications.
Mistake
You can assign an RBAC role directly to an app registration.
Correct
RBAC roles are assigned to the service principal (enterprise application), not the app registration. The app registration is only a definition; the service principal is the security principal that can be assigned roles.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An app registration is the global application object that defines metadata (redirect URIs, permissions, credentials) in a single tenant. A service principal is the local representation of that app in a specific tenant, which is used for authentication and authorization. When you register an app, a service principal is automatically created in the same tenant. For multi-tenant apps, a service principal is created in each tenant where the app is consented. For exam purposes, remember: app registration = blueprint, service principal = actual identity.
You assign the role to the service principal (enterprise application), not the app registration. In Azure portal, go to the resource, select Access control (IAM) > Add role assignment. Search for the service principal by name (the enterprise app name, which is usually the same as the app registration name). Select the role (e.g., Contributor) and save. Alternatively, use Azure CLI: az role assignment create --assignee <service-principal-object-id> --role Contributor --resource-group MyRG. The service principal object ID can be found in Azure AD > Enterprise applications > select the app > Properties.
The client credentials grant flow is an OAuth 2.0 flow where an application authenticates using its own credentials (client ID and secret/certificate) without a user. It is used for server-to-server scenarios. The app requests a token from the token endpoint with grant_type=client_credentials and scope=<resource>/.default. The token represents the application itself (not a user). This flow is commonly used by background services, daemons, and scripts. In the exam, remember that this flow requires application permissions (not delegated) and admin consent.
Yes, but with limitations. Conditional Access policies can target service principals (enterprise apps) for scenarios like requiring MFA or blocking access from untrusted locations. However, this is in preview and only works for certain app types (e.g., Azure Management, Microsoft Graph). The policy is applied to the service principal itself, not to users. For example, you can require that a service principal authenticating to Microsoft Graph must come from a specific IP range. Most exam questions focus on user-based Conditional Access, but be aware of service principal targeting.
This error means 'Application with identifier was not found in the directory'. It occurs when the client ID or tenant ID in the authentication request is incorrect. Verify that the client ID matches the app registration's Application (client) ID. Also check that the tenant ID is correct (you can find it in Azure AD > Overview > Tenant ID). If the app is multi-tenant, ensure you are using the correct tenant endpoint (e.g., https://login.microsoftonline.com/{customer-tenant-id}/oauth2/v2.0/token). Another cause: the app registration may have been deleted. Check that the app exists in Azure AD > App registrations.
Delegated permissions allow the app to act on behalf of a signed-in user. The app has the permissions that the user has, plus any delegated permissions granted to the app. For example, if the user can read their own profile, the app can read it too. Application permissions allow the app to act as itself, without a user. For example, the app can read all users' profiles regardless of individual user permissions. Application permissions always require admin consent. The exam often tests: if the app needs to access data without a user present (e.g., background service), use application permissions.
In the app registration, go to Certificates & secrets. Add a new secret (with a new value). Update your application code to use the new secret. After confirming the new secret works, delete the old secret. Best practice: use two secrets overlapping (add second, update app, delete first) to avoid downtime. For production, consider using certificates or managed identities to avoid secret rotation altogether. The exam may ask about secret expiration: maximum lifetime is 2 years, and you should rotate before expiration.
You've just covered App Registrations and Service Principals — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?