Why You Should Create a Bearer Token with Application Permission Instead of Delegated Permission in HTTP Requests in Power Automate

Power Automate is a powerful automation tool that enables businesses to streamline processes and integrate with various services. When making HTTP requests to external APIs in Power Automate, authentication is a critical step, ensuring secure communication between the flow and the API. One of the common authentication methods involves using Bearer Tokens, which can be granted via Application Permissions or Delegated Permissions.

Understanding the differences between these two authentication methods is crucial for choosing the right approach. In many cases, using a Bearer Token with Application Permissions is preferable to Delegated Permissions due to its flexibility, security, and independence from user sessions. This article explores the key reasons why application permissions should be used over delegated permissions when making HTTP requests in Power Automate.

1. Understanding Bearer Tokens in Power Automate

A Bearer Token is a type of access token used in authentication protocols like OAuth 2.0. It is included in the Authorization header of an HTTP request to prove the identity of the requester. In Power Automate, Bearer Tokens are commonly used when calling APIs such as Microsoft Graph, SharePoint, or third-party services.

There are two main ways to acquire a Bearer Token:

• Application Permissions: The token is granted to an application itself, without requiring a logged-in user. The application acts on its own identity.
• Delegated Permissions: The token is granted on behalf of a signed-in user, meaning the API call operates under the user’s identity and permissions.

Both methods have their use cases, but Application Permissions offer several advantages over Delegated Permissions in automated workflows.

2. Independence from User Context

One of the biggest advantages of using Application Permissions is that they do not require a user to be signed in. With Delegated Permissions, an authenticated user must be present in order for the API request to work. This dependency creates issues in unattended automation, such as:

• If a user logs out, the flow may fail.
• Scheduled or background processes cannot function properly without a user session.
• Service accounts may need constant re-authentication, adding complexity to automation.

Since Application Permissions work at the service level, Power Automate flows can run independently without requiring a logged-in user, making them ideal for background tasks and system integrations.

3. Higher Security and Granular Control

Using Application Permissions improves security by reducing the need for user credentials. Delegated Permissions require user authentication, which may expose access tokens to potential misuse. Some key security benefits of Application Permissions include:

• Reduced Risk of Credential Leakage: Since authentication is handled at the application level, there’s no need to store or share user credentials.
• Granular Role-Based Access Control (RBAC): Admins can grant least privilege access to the application, ensuring it only has the permissions required to perform its function.
• No Session Expiry Issues: Delegated tokens typically have a shorter lifespan, requiring frequent re-authentication. Application tokens can be managed more predictably, reducing potential failures.

4. Better Scalability for Enterprise Applications

In enterprise environments, scalability is key when designing automated workflows. Application Permissions enable seamless scaling of Power Automate flows across multiple users, departments, or even organizations. Some reasons why Application Permissions are more scalable include:

• The token does not depend on any single user, making it easy to distribute across multiple automated processes.
• It simplifies API authentication in multi-user scenarios, where different users might have varying permissions when using Delegated Tokens.
• Centralized access control ensures that permissions are managed at an organizational level, rather than at an individual user level.

By contrast, Delegated Permissions limit API requests to the authenticated user’s permissions, making it difficult to scale workflows that require broader access.

5. Consistent and Reliable API Requests

Since Delegated Permissions rely on a user's session, there can be inconsistencies in API behavior depending on the permissions granted to the user. This can lead to:

• Unauthorized access errors when the user lacks the necessary permissions.
• Unexpected failures if the user’s authentication token expires.
• Variability in API responses based on the user’s access level.

With Application Permissions, the API request is always executed with the same predefined level of access, ensuring consistent and reliable results. This is particularly useful for system-to-system integrations where predictability is important.

6. When to Use Delegated Permissions Instead

While Application Permissions are generally preferable for automation, there are scenarios where Delegated Permissions may be necessary:

• User-Specific Actions: If the API request should execute under a specific user’s identity (e.g., sending an email on behalf of a user), Delegated Permissions are required.
• Limited Access Needs: If the automation should only access data that the signed-in user has permission to see, Delegated Permissions provide a more restrictive access model.
• Interactive Processes: If user approval or input is required in real-time, Delegated Permissions make sense since they authenticate against a live user session.

With Application Permissions, the API request is always executed with the same predefined level of access, ensuring consistent and reliable results. This is particularly useful for system-to-system integrations where predictability is important.

7. How to Get a Bearer Token with Application Permissions in Power Automate

To obtain a Bearer Token using Application Permissions in Power Automate, follow these steps:

Step 1: Register an App in Azure AD

1. Go to Azure Portal → Azure Active Directory → App Registrations.
2. Click New Registration and enter the required details.
3. In API Permissions, add the necessary Application Permissions (e.g., Microsoft Graph, SharePoint).
4. Grant admin consent for the organization.

Step 2: Generate a Client Secret or Certificate

1. In Certificates & Secrets, generate a new client secret and copy its value.
2. Alternatively, upload a certificate for added security.

Step 3: Get a Token Using HTTP Request in Power Automate

Use an HTTP request in Power Automate to retrieve a Bearer Token:

Request URL:

https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token        

Headers:

Content-Type: application/x-www-form-urlencoded        

Body (for client credentials flow):

grant_type=client_credentials client_id={your_client_id} client_secret={your_client_secret} scope=https://graph.microsoft.com/.default        

Step 4: Use the Token in API Calls Once you retrieve the token, include it in API requests as:

Authorization: Bearer {access_token}        

This allows the flow to authenticate without a user context, using only the application’s permissions.

Summary

When automating API requests in Power Automate, Application Permissions are often a better choice than Delegated Permissions. They provide greater security, scalability, reliability, and independence from user sessions, making them ideal for background processes and system integrations. While Delegated Permissions have their place in user-specific workflows, most automation tasks benefit from using Application Permissions for better control and efficiency.

By implementing Bearer Tokens with Application Permissions, businesses can build robust and secure automated workflows that run seamlessly without requiring user interaction.