Delegated vs Application Permissions: OAuth Scopes vs App Roles in SaaS

The same permission name can mean "read this user's files" or "read every file in the tenant", depending on whether it was granted as a delegated scope or as an application permission. Delegated permissions let an app act on behalf of a signed-in user and are bounded by that user's own access. Application permissions, which Microsoft Entra ID calls app roles, let an app act as itself with no user present, so the permission is the whole limit. This guide compares the two models across major SaaS platforms, sets out the threat model for each, and gives the decision criteria, review controls and metrics for choosing between them. It is for identity, SaaS and security teams approving integrations. Platforms are listed alphabetically; order is never a ranking.

Key takeaways

• Delegated access is an intersection; application access is a grant. Microsoft's documentation states that a delegated app cannot access anything the signed-in user could not, while an application permission lets the app access any data the permission covers.
• Tenant-wide reach is the deciding risk factor. Application permissions, Google Workspace domain-wide delegation and admin-installed bot tokens all reach data for every user, so one leaked credential exposes the whole tenant.
• Consent phishing targets delegated scopes; app-only abuse targets credentials. The first tricks a user into granting access; the second steals or plants a client secret, key or token for an app that already holds broad roles.
• Every platform has its own vocabulary for the same split. Bot versus user tokens in Slack, integration users in Salesforce, scopes plus admin roles in Okta, domain-wide delegation in Google Workspace, scopes versus app roles in Entra ID.
• Default to delegated, justify application. Choose app-only access only when there is genuinely no user, then narrow it with resource scoping, admin roles or integration-user permissions and review it on a fixed cadence.

The two models in one table

The underlying OAuth idea is covered in the OAuth Scope Design Guide, which explains how to design scopes for your own APIs. This page is about approving and governing grants on the SaaS platforms you consume.

How each platform implements the split

Each subsection describes the platform's own model from its public documentation, as checked in November 2026. Product behaviour changes, so confirm settings against current vendor documentation.

Google Workspace

Delegated: third-party apps request OAuth scopes and users consent, subject to the admin's API access controls. App-only equivalent: domain-wide delegation lets a super administrator authorise a service account or OAuth client ID for a list of OAuth scopes, after which the app can access those scopes for users without their consent. Google's documentation stresses that delegation reaches data for all users in the domain. Setting: Security, Access and data control, API controls, Manage Domain Wide Delegation. Guidance from the docs: keep scopes narrow, review them periodically, delete clients no longer needed (for example a finished migration tool) and review service accounts. Changes can take up to 24 hours to apply, and multi-party approval can require a second super admin. See How to audit Google Workspace domain-wide delegation grants.

Microsoft Entra ID

Delegated: OAuth2 permission scopes such as Files.Read.All, limited to what the signed-in user can access. Users can consent for their own data where policy allows, and admins can consent for all users. App-only: application permissions, also called app roles, consented only by an administrator. The same Files.Read.All granted as an application permission reads any file in the tenant through Microsoft Graph. A client credentials request must use {resource}/.default and receives every app role granted for that API, so the app cannot down-scope at request time. Setting: user consent settings, the admin consent workflow and publisher verification. See How to restrict user consent to apps in Entra ID.

Okta

Delegated: apps acting for a signed-in administrator request okta.* scopes in a user-based flow, so the administrator's own role still applies. App-only: service apps use the client credentials flow, the only flow that mints Okta-scoped tokens for service apps, with private_key_jwt client authentication. A service app's effective access is the intersection of its granted scopes and its assigned admin role: scopes control endpoints and actions, the role controls resources. Only a Super Admin can grant scopes. Guidance from the docs: assign a standard or custom admin role to every service app, and turn off the "Public client app admins" setting, which grants SUPER_ADMIN automatically once scopes are granted, after role assignment is part of your workflow. Okta-scoped access tokens for service apps last one hour. See How to audit Okta API tokens and service apps.

Salesforce

Delegated: connected and external client apps request OAuth scopes such as api, and the token acts with the authorising user's permissions. App-only equivalent: the client credentials flow issues tokens on behalf of an assigned integration (Run As) user, whose permissions govern what the app can access. Scopes are assigned to the app rather than requested at the token endpoint, refresh tokens are not issued for this flow, and it must use the org's My Domain URL. Guidance from the docs: protect and periodically rotate the consumer key and secret, and send them in the POST body or Basic header, never in a query string. Because the integration user's profile and permission sets are the real limit, review them like a privileged account. See How to review Salesforce connected apps and integration users.

Slack

Delegated: user tokens (xoxp-) act with the installing or authenticating user's own access, and writes appear as that user. App-only equivalent: bot tokens (xoxb-) represent a bot tied to the app, not to any person, carry the bot's own granular scopes and remain valid if the installing user is deactivated. Guidance from the docs: use bot tokens by default and user tokens only when you need to act on behalf of a user; avoid legacy bot tokens, which use an umbrella bot scope. Here the platform's default runs towards app identity, so governance focuses on which bot scopes are approved and which channels the bot joins. See How to audit Slack apps, bots and tokens.

Threat model: delegated permissions

• Consent phishing: Microsoft describes it as tricking users into granting permissions to a malicious app; no password is needed, and the prompt is hosted by the legitimate identity platform, which makes it look trustworthy. ATT&CK tracks the delivery as T1566.002 Phishing: Spearphishing Link and the token theft as T1528 Steal Application Access Token. See the Consent Phishing and Illicit OAuth Grants Guide.
• Admin consent as the prize: when an attacker phishes an administrator, delegated scopes for that admin can approach tenant-wide reach, because the user's rights are themselves broad.
• Long-lived refresh tokens: in Entra ID, offline_access appears to users as "Maintain access to data you have given it access to"; refresh tokens are typically valid for 90 days, so a delegated grant outlives the session that created it.
• Vendor-held tokens: a SaaS integration that stores users' delegated tokens becomes a target in its own right. The Salesloft Drift breach showed attackers calling customer Salesforce APIs as a trusted app using stolen OAuth access and refresh tokens.

Threat model: application permissions

• Credential theft gives tenant reach: a leaked client secret, private key, service account key or bot token is all an attacker needs, with no user interaction and no MFA in the path.
• Privilege accumulation on forgotten apps: test and migration apps keep their roles after the project ends. In the Microsoft Midnight Blizzard breach, the actor compromised a legacy test OAuth application with elevated access and used it to grant the Exchange Online full_access_as_app role, an application permission that reads mailboxes without signing in as each user.
• Coarse grants that cannot be narrowed at runtime: Entra ID's .default behaviour means the app gets every granted role on every call, so over-granting is permanent until someone removes it.
• Weak attribution: audit logs record the app, not a human, so misuse blends into normal integration activity unless you baseline it.

Decision criteria

• Prefer delegated when: a user drives the action, data should follow their access, and you want the human in the audit trail.
• Accept application when: there is no user and you can narrow access with the platform's control: an admin role in Okta, a restricted integration user in Salesforce, a minimal domain-wide delegation scope list in Google Workspace, limited app roles in Entra ID, or minimal bot scopes in Slack.
• Small organisations: the realistic control is admin-only consent for anything tenant-wide, plus a quarterly review of every app holding application permissions.
• Large organisations: route all app-only requests through an approval workflow with a named owner, data classification and expiry date, and feed grants into identity governance. See the SaaS and OAuth App Governance Guide.

Worked scenario

A sales team asks for a meeting-notes tool that reads calendars and writes summaries to CRM records. The vendor's default request is app-only calendar access across the tenant and a client credentials integration in the CRM. Reviewing it against the criteria: a user starts each recording, data should follow that user, and only sales staff need the feature. The approved design uses delegated calendar scopes with admin consent scoped to a sales group, and a CRM integration user limited by permission set to the objects the tool writes. The tool's refresh tokens are reviewed at contract renewal, and the integration user is recorded as a non-human identity with an owner.

Controls that apply to both

• Restrict user consent: allow users to consent only to verified publishers or low-risk scopes you choose, and route everything else to an admin consent request, as Microsoft recommends for consent phishing.
• Admin consent with evidence: record business owner, data accessed, model chosen (delegated or application) and review date for every grant.
• Least privilege by design: read before write, specific resources before tenant-wide, and no legacy umbrella scopes.
• Credential hygiene for app-only: certificates or private-key JWT over shared secrets, storage in a secrets manager, rotation on a schedule and immediately on suspicion. See the Machine-to-Machine OAuth (Client Credentials) Guide.
• Offboarding: delete clients and service accounts when projects end; Google notes that dependent apps stop working immediately, so confirm the owner first.

How to implement a review programme

1. Inventory: export every OAuth grant and app-only identity from each platform, tagging each as delegated or application and noting tenant-wide reach.
2. Rank by reach: review tenant-wide application grants, domain-wide delegation clients and high-privilege delegated admin grants first.
3. Assign owners: every app-only identity gets a named human owner; grants without an owner are scheduled for removal.
4. Tighten consent policy in audit mode: where the platform supports it, start by routing new requests to admin review without revoking existing grants, so you learn the demand before breaking anything.
5. Reduce: remove unused scopes and roles in batches, notifying owners first and keeping a record of the previous grant so it can be restored if a business process fails.
6. Convert where possible: move integrations that have a user in the loop from application to delegated access.
7. Repeat: quarterly for app-only and admin-consented grants, annually for low-risk user grants.

Detection and measurement

• Watch for: new application permission or app role grants, new domain-wide delegation clients, new Okta scope grants to service apps, changes to Salesforce integration user permissions, new Slack apps with broad bot scopes, and consents by users who rarely approve apps.
• Baseline app-only activity: alert on bulk exports, new source IPs or anonymising networks, and calls to APIs the app has never used. The Drift lessons include alerting on bulk exports and integration activity from anonymising proxies.

Metrics:

• Number of apps holding tenant-wide application permissions or equivalent, with trend.
• Percentage of app-only identities with a named owner and review date.
• Percentage of new consent requests handled through the admin workflow.
• Median age of app-only credentials and percentage using certificates or keys rather than shared secrets.
• Grants removed per review cycle as a share of grants reviewed.

Common failure patterns

• Accepting the vendor's default request: integrations ask for app-only, tenant-wide access because it is simpler to build, and nobody asks whether a user is present.
• Treating "admin consented" as "reviewed": the consent click records approval, not justification, owner or expiry.
• Leaving test and migration apps in place: the Midnight Blizzard case shows how a legacy test app with elevated access became a route to mailboxes.
• Ignoring the integration user: in Salesforce the Run As user's permissions are the real limit; a system administrator profile there turns a narrow integration into full org access.
• Auto-granting super admin: leaving Okta's "Public client app admins" setting on after adopting role-based service apps.
• Forgetting tokens held by vendors: grants are reviewed in your tenant, but the vendor's store of your users' refresh tokens is not, as the Drift incident illustrates.

Framework mapping

Practitioner checklist

• Every OAuth grant is labelled delegated or application, with tenant-wide reach flagged.
• User consent is limited to verified publishers or chosen low-risk scopes; everything else goes to an admin workflow.
• Each app-only identity has an owner, justification, data scope and review date.
• Domain-wide delegation clients, Okta service app scopes and roles, Salesforce integration users, Slack bot scopes and Entra ID app roles are reviewed quarterly.
• App-only credentials are certificates or keys held in a secrets manager, rotated on a schedule.
• Test, migration and ownerless apps are removed after confirmation with the owner.
• Alerts exist for new high-privilege grants and anomalous bulk activity by integrations.
• Vendor contracts cover how the vendor stores and protects your users' tokens.

Standards and references

• Microsoft: Overview of permissions and consent in the Microsoft identity platform
• Microsoft: Scopes and permissions in the Microsoft identity platform
• Microsoft: Protect against consent phishing
• Google: Control API access with domain-wide delegation
• Okta: Implement OAuth for Okta with a service app
• Salesforce: OAuth 2.0 Client Credentials Flow for Server-to-Server Integration
• Slack: Tokens
• IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security

Related NHI Mgmt Group resources: Entra ID Applications and Consent Guide · SaaS and OAuth App Governance Guide · How to find high-privilege Microsoft Graph application permissions · OAuth Scope Design Guide