Selecting the wrong token type can lead to either an exposed, over-privileged backend service or an unworkable user flow. Let's break down how each token operates under the hood, when to use them, and how to avoid identity misconfigurations.

Understanding the Difference At a high level, the distinction comes down to context: Is a human actively driving the action, or is a background process running autonomously?

1. Delegated Tokens (User Context + Application) OAuth Flow: Authorization Code Flow with PKCE, On-Behalf-Of (OBO) Flow.

How It Works: The token represents two identities simultaneously: the signed-in User and the Client Application making the call.

Effective Permissions: The API evaluates the intersection of what the application is allowed to do and what the user is allowed to do. If an app has Files.ReadWrite.All delegated permission, but the logged-in user only has access to folder "Marketing," the app can only access folder "Marketing."

Best Used For: Web applications, mobile apps, Single Page Applications (SPAs), and CLI tools where actions must strictly track back to an individual user's authorization.

1. Application Tokens (App-Only Context)

OAuth Flow: Client Credentials Grant.

How It Works: The token represents only the Application itself. No user is involved.

Effective Permissions: The token holds direct roles assigned to the application service principal. The target API grants access based purely on the application's credentials (client secret or certificate).

Best Used For: Background daemons, nightly sync scripts, cron jobs, event consumers, and inter-service

Security Pitfalls to Avoid

Warning: Assigning Application Permissions like DirectoryReadWrite.All or Mail.Read without restrictions gives your background service tenant-wide access. If that app's secret leaks, your entire directory is exposed.

1. Over-Privileging Service Principals: If a background process only needs to read emails from a specific support inbox, don't assign Mail.Read globally via Application Permissions without scoping mechanisms like Application Access Policies in Exchange Online.

2. Confused Deputy Problem: Avoid using Application tokens to process requests that originated from a user UI. If User A asks your backend API to fetch a document, call Microsoft Graph using a Delegated token (or OBO flow), not an Application token. Using an Application token bypasses User A's real access controls, letting them query documents they shouldn't see.

Frequently Asked Questions

Q: Can I use Delegated tokens for long-running, offline processes? Yes, using OAuth 2.0 refresh_tokens or the offline_access scope. However, if the user changes their password, revokes sessions, or leaves the company, the refresh token invalidates—which is usually desired behavior for user-driven tasks.

Q: How do I secure Application Tokens when using Client Credentials? Never use plain text client secrets in code repositories. Use Azure Managed Identities, AWS IAM Roles for Service Accounts (IRSA), or client certificate credentials backed by a Hardware Security Module (HSM) / Azure Key Vault.