4.2 App Registrations, Permission Scopes & Service Principal Credentials

The Object Model: Application vs Service Principal

When you create an app registration, Microsoft Entra ID creates an application object in the tenant where you registered it (the home tenant). The application object is the global template: display name, sign-in audience, redirect URIs, credentials, requested permissions, and any API surface the app publishes.

A service principal is the local instance of that application in a tenant. It is created automatically the first time the app is consented to or assigned. Everything tenant-specific lives on the service principal: permission grants, user assignments, sign-in enablement, and Conditional Access targeting.

A multi-tenant SaaS app therefore has one application object at the vendor and one service principal in each customer tenant. That is why removing a vendor’s access is a service principal operation in your tenant, not a request to the vendor.

---

Credentials: Secrets, Certificates, and Federated Identity

Two controls belong in an AZ-500 answer about credential hygiene:

• The application authentication methods policy (an Entra ID application management policy) can block password credentials outright or restrict their maximum lifetime, tenant-wide or per application. This is how you enforce "certificates only" rather than relying on developer discipline.
• Managed identities, covered in the workload identity section, remove credentials entirely for anything running on an Azure resource. On the exam, prefer a managed identity whenever the workload runs in Azure; prefer workload identity federation when it runs outside Azure; use a certificate only when neither is possible; use a client secret last.

Rotation is an operational requirement, not an optional one: expired credentials cause outages, and long-lived ones cause breaches. Monitor upcoming expiry with Microsoft Graph (Get-MgApplication and inspect passwordCredentials/keyCredentials end dates) and alert well before the date.

---

Exposing an API: Scopes and App Roles

When your own application publishes an API that other applications call, the registration must declare what callers may request.

Expose an API defines:

• An Application ID URI, such as api://<appId> or a verified custom domain URI. This is the token audience.
• Scopes (delegated permissions), each with an admin consent display name and description, an optional user consent description, and a Who can consent setting of Admins only or Admins and users. Marking a destructive scope as Admins only prevents self-service escalation.
• Authorized client applications — pre-authorizing a known client for a specific scope so that its users never see a consent prompt. Use sparingly; each entry is a standing trust.

App roles define application-only permissions (and can also define user roles surfaced in the roles claim). A daemon calling your API receives an app role assignment rather than a delegated scope.

The API permissions blade on the caller side is the mirror image: it lists which permissions the app requests. Requesting a permission does not grant it — the grant only exists after consent.

Least-privilege permissions for automation

An automation account that manages application objects should not receive Application.ReadWrite.All, which reaches every registration in the directory. Use Application.ReadWrite.OwnedBy, which limits writes to applications where the principal is listed as an owner. This is a favourite exam contrast.

---

Administrative Roles That Can Take Over Applications

Any role that can add a credential to an application can become that application, inheriting all of its permissions. Treat these as privileged:

Practical controls: turn off Users can register applications in User settings so registration is deliberate, make these roles eligible in Privileged Identity Management (PIM) rather than permanently assigned, and run access reviews over application owners. Auditing application ownership is as important as auditing directory role membership, because ownership is a quiet, permanent escalation route that most reviews miss.