An app cannot check its inbox for a login code. When an app, script, or deployment pipeline needs access to Azure resources, a service principal gives it a nonhuman identity. It can authenticate and be authorized without borrowing someone’s personal account. section 6.6.2 section 6.9
Service principals belong to Azure’s identity-and-access picture: Microsoft Entra ID handles identities, while role-based access control (RBAC) determines what an identity may do. Giving a deployment bot an identity is not the same as giving it permission to touch everything. section 6.6 section 6.9
To create one for an application in the Azure portal:
- Open Microsoft Entra ID, go to App registrations, and select New registration. Registering the app creates a corresponding service principal. section 6.6.2
- Under Certificates & secrets, create a client secret and choose its expiry. Copy its value to a safe place immediately; Azure shows it only once. section 6.6.2
- Keep the application (client) ID, directory (tenant) ID, and client secret available for the application’s authentication setup. Plan to rotate the secret when it expires. section 6.6.2
A deployment pipeline needs its own identity
A GitHub Actions workflow or Terraform deployment can use a service principal rather than a person’s credentials. Service principals are also useful for applications running outside Azure. For an Azure-native service such as App Service or Function App, consider a managed identity instead: it lets the service authenticate without storing credentials. section 6.6.2 section 6.9
