How do scopes and permissions work in the Microsoft identity platform?

What scopes and permissions mean in Microsoft identity platform apps

Scopes and permissions sit at the center of how an app is allowed to act. A scope is what the app asks for during sign-in or consent, while a permission is what the platform ultimately grants. That distinction matters because the same app can be limited to a user’s delegated access or allowed to act directly as itself in an application flow.

In practice, scopes shape the consent experience and permissions shape the runtime authority. A delegated token should reflect the user’s access plus the app’s approved scope, which is why overbroad scope requests are a common design mistake. For app-only access, the permission grant is the real control point, so the question becomes whether the app should be trusted with that level of authority at all.

Microsoft’s model also makes the Entra ID Applications and Consent Guide relevant for understanding how enterprise apps, delegated permissions, application permissions, and admin consent fit together. If you are reviewing an app request, the main task is to separate what the application is asking for from what the tenant has actually agreed to grant.

Why minimum-scope design matters in delegated and app-only flows

Least privilege is not just a general security slogan here, it is how you keep consent from turning into broad, durable access. In delegated flows, the user’s own role and the requested scopes both constrain the token. In application flows, the app’s permission set can become effectively standing authority, so a careless grant can give the workload far more reach than the business use case justifies.

That is why scope selection should be treated as an authorization design choice, not a developer convenience. The Authorisation Models Guide is useful when you need to decide whether a broad scope should be replaced with finer-grained control at the API or policy layer. For Microsoft identity platform apps, the right pattern is usually to request the narrowest scope that still supports the transaction, then expand only when a new business requirement is explicit.

When broader permissions are unavoidable, the control question changes from “is this app useful?” to “is this app trustworthy enough to hold this level of access?” That is where the difference between user consent, admin consent, and app-only authority becomes operationally important.

How to review consent, privilege, and lifecycle before an app goes live

Consent review should focus on who can grant it, what resource is being exposed, and whether the app’s permission set matches the intended use. Broad permissions become dangerous when they are granted once and then left unchanged as the app evolves. Revalidation matters because integrations drift, owners change, and older permissions often outlive the original justification.

That lifecycle view is why the Privileged Access Management Guide is a good companion for app permission decisions. Where scopes or permissions create powerful access, treat them like privileged access: review them, limit who can approve them, and define a clear path to revoke them when the app no longer needs them. If the app can act without a human present, the governance bar should be higher, not lower.

For ongoing administration, the NHI Lifecycle Management Guide helps frame the operational side of permission hygiene. The same logic that applies to other long-lived access relationships applies here too: inventory what exists, know who owns it, and remove access that is no longer justified.

Risk and Threat Considerations

Overbroad scopes and permissions create two common failure modes: excessive delegated authority and excessive app-only authority. In the first case, a compromised user session can do more than the user intended because the app was granted too much access. In the second, an application credential or consent grant can expose a wider attack path because the app itself is trusted to act independently.

Failure mechanism: Attackers often target consent abuse, token theft, or overpermissive application grants to turn a legitimate integration into a durable access path. Once a broad permission is accepted, the attacker may not need to bypass the platform again, they only need to reuse the granted authority.

Impact: The result can be mailbox, file, directory, or API data exposure, plus lateral movement through connected SaaS or Microsoft 365 workloads. The wider the permission, the larger the blast radius when the app, user, or approval path is abused.

Practitioner Guidance

What to verify: Confirm whether the app truly needs delegated access, app-only access, or both, and test the request against the minimum viable resource list. If the requested scope is broader than the workflow, treat that as a design defect rather than a cosmetic review issue.

Decision rule: If the app needs a high-impact permission, require documented business justification, explicit approver ownership, and a plan to review the grant after deployment. If it does not, narrow the scope or redesign the integration before consent is granted.

Practitioner takeaway: The important distinction is not just what an app asks for, but what authority the tenant is willing to let it keep; treat scopes as the request and permissions as the enforceable trust boundary.

Related resources from NHI Mgmt Group

• Who should own identity and device governance in a consolidated work platform?
• What breaks when Microsoft identity permissions are not fully audited before AI rollout?
• How should organisations secure remote onboarding when identity proofing must work across mixed Microsoft and non-Microsoft environments?
• Who is accountable when role changes immediately affect permissions across an identity platform?