Service principal (app identity)
What it is
A service principal is the Microsoft Entra identity that represents an application, automation process, or service inside a tenant. It lets a non-human workload sign in and then receive permissions. Think of it as Northwind’s employee badge for software, not an extra human account.
Why it exists
Apps and automation need to authenticate and be authorized without human credentials. A service principal can use a certificate, client secret, or federated credential; CI/CD (Pipelines/github-actions), scripts, and services then receive only the RBAC access they need.
Key ideas
- An application object describes an application. A service principal is that application’s local identity representation in a tenant. An application can have service principals in multiple tenants.
- A service principal can authenticate using a certificate, a client secret, or a federated credential. Credentials are sensitive; prefer a managed identity for supported Azure-hosted workloads, or federation for supported external automation.
- Authentication proves the software’s identity. RBAC or a service’s own authorization then grants the minimum access it needs.
- A managed identity has a backing service principal, but Azure manages its credentials and lifecycle differently from an application registration.
Northwind example
Northwind’s deployment system needs permission to deploy the ordering application. It uses a service principal with a federated credential rather than saving a long-lived client secret in the pipeline. Maya grants that identity only the deployment permissions it needs at the production resource-group scope. The pipeline can authenticate as its service principal, but it cannot read order receipts unless a separate data permission is granted.
Common confusion
- A service principal is not automatically an administrator. It has no useful Azure access until a role assignment or service-specific authorization grants it.
- A client secret is a credential for a service principal, not the service principal itself.
- Do not use a shared human user account as an application’s identity. It obscures accountability and makes rotation/offboarding unsafe.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: entra/identity-platform/app-objects-and-service-principals
Exam notes
- Managed identities are the recommended way to give Azure workloads access to Azure resources.
- System-assigned (tied to one resource) vs user-assigned (shared across resources) — know the difference.
- Service principals need the right role (e.g. Contributor, or a custom role) — least privilege.
Related
entraid · rbac · user-account · managed-identity · key-vault · azure-pipelines · northwind-traders-case-study
📘 Source: Microsoft Learn — Application and service principal objects, checked 2026-09-16. Re-audit when service-principal, managed-identity, or workload-federation behavior changes.