Application Permissions

Application permissions in Microsoft Entra ID are OAuth permission scopes where an application acts on its own, without a signed-in user. The app uses its own credentials (client secret, certificate, or federated identity) to obtain tokens. Permissions are evaluated against the app's identity alone, typically granting tenant-wide access — Mail.Read (application) reads every mailbox in the tenant, User.Read.All reads every user. Used for backend services, scheduled jobs, system integrations without user interaction. Require admin consent to grant. Contrast with delegated permissions which act on behalf of a signed-in user with that user's scope.

Worked example

A nightly reporting job needs to pull mailbox statistics for every user in the tenant to build a usage dashboard. Because it runs unattended at 2am with nobody signed in, it's registered as an app in Entra ID with the application permission Mail.Read (application, not delegated) and authenticates using a certificate rather than a client secret. An admin grants tenant-wide consent for that permission once, and from then on the job's certificate-based credential is enough for it to read every mailbox in the tenant on its own schedule, with no user ever having to be present.

Common pitfalls

Granting an application permission broader than a job actually needs — Mail.ReadWrite when the job only ever reads — is the most consequential mistake here, because application permissions apply tenant-wide with no user context to naturally limit blast radius if the credential is ever compromised. Storing the app's client secret in plaintext in a script or config file rather than in a proper secret store, or using a long-lived secret instead of a certificate or managed identity, turns that tenant-wide access into an easy target for credential theft. And treating admin consent as a one-time formality rather than a real security control skips the review step that application permissions specifically require — unlike delegated permissions, there's no signed-in user's own access acting as a natural ceiling on the damage a compromised or malicious app could do.