Authentication

Part of Workflow authentication and secrets

Comparing API keys with delegated and application access

Choose a workflow credential by asking whose authority the action should use and what it must be able to do.

Desk Integration · · 3 min read

Choose among an API key, delegated access and app-only access by matching the workflow’s identity to its required actions. A key identifies an application or integration; delegated OAuth 2.0 permissions apply to a signed-in user, while application permissions belong directly to an app. Their grants and failure modes differ: a label alone does not make one safer.

Match identity to the task

An API key is a secret credential that identifies an application or integration. What it grants depends on the provider: a key may represent an account, project or restricted service scope, so check whether its access covers the workflow’s required reads and writes.

OAuth 2.0 access tokens carry permissions for an application to access a service. Scopes define permitted actions, such as read-only access or access to particular endpoints; the app sends the token in an HTTP header such as Authorization: Bearer ….

In the Microsoft identity platform, delegated permissions are granted to a signed-in user, while application permissions are granted directly to the app. Delegated permissions require user sign-in; application permissions do not, use the client credentials grant flow and require admin consent configured in Microsoft Entra App Registration.

To identify the permission type in a Microsoft access token, inspect its claims with jwt.ms. Delegated permissions appear in the scp claim, such as Directory.Read.All User.Read; application permissions appear in roles, such as User.Read.All. A delegated token can also contain roles for roles assigned to the user in the API app.

API Key vs Delegated vs Application Access: Key Differences

Identity Used
Application or integration
Authentication Context
Signed-in user (delegated) or application (app-only)
User Interaction Required
No (API key), Yes (delegated), No (application permissions)
Consent Requirement
None (API key), User consent (delegated), Admin consent (application)
Token Type
API key (secret), OAuth 2.0 access token with `scp` (delegated), `roles` (application)

How to Choose the Right Access Method

  1. Identify who should perform the actionIs it a person? Use delegated access. Is it an automated system? Consider app-only or API key.
  2. Determine required scope of accessDoes it need full access or just read-only? Aim for least privilege using restricted keys or scoped permissions.
  3. Check if admin consent is availableFor application permissions in Microsoft Entra, admin consent must be granted via App Registration in Azure portal.
  4. Test both permitted and forbidden actionsEnsure the credential grants only what is needed and denies unwanted operations.

Plan for people and failures

Use delegated access when an action should run in a signed-in person’s context. For an unattended workflow, application permissions may suit the task where the API supports them; use an API key only when its provider-defined grant fits the work, and test both a permitted action and a forbidden one.

OAuth access tokens are short-lived, and a refresh token can renew an expired access token without new user interaction. An app’s own credential, such as its client ID and secret or assertion, is separate from the access token and may continue indefinitely unless someone owns its rotation.

Delegated access depends on user sign-in and may fail when the person leaves or consent changes. Application permissions require admin consent, while a key copied into several workflows can make emergency revocation disruptive.

A broad key can grant more than the job needs; look for a restricted key or intermediary service if one is available. Shared secrets also make identifying the source of a leak or compromise challenging, so review the grant when a workflow changes rather than silently extending its privileges.

Pros and Cons of Each Access Method

  • API KeyPros: Simple to implement, no user sign-in needed. Cons: Hard to revoke if shared, risk of broad access, difficult to trace misuse.
  • Delegated AccessPros: Action runs under a user’s identity, good for user-specific workflows. Cons: Fails if user leaves or consent changes, requires user interaction for initial setup.
  • Application PermissionsPros: Enables unattended workflows, no user sign-in needed. Cons: Requires admin consent, higher privilege level, harder to audit if misused.

More from Authentication