Summary:
When calling Microsoft Flow from PowerApps, there is absolutely no trust-free-secure way to validate which user called the flow from Power Apps. Unable to use Microsoft flow as a secure API to power apps.
Scenario:
Lets say I have a power automate flow with the following features/requirements:
Lets say I have a power app with the following features/requirements:
To achieve this, I can pass a parameter (say username/email) to the flow from power apps using PowerApps trigger. Simple right?
Well, there is clearly a security issue here if you solve the problem this way. Here's why
Since Microsoft Flow's PowerApps trigger has no way to provide user context information, the backend flow cannot be validated. It has to trust that the caller doesn't mess with the body. Essentially making it unsecure to use Microsoft flow as an API to power apps.
If you create a normal flow without a power apps trigger, you actually have user context information. You don't need to send as an input since flow already has access to the authenticated user's context. This same functionality should be provided along with power apps trigger.
So why is Power Automate's power apps trigger built this way? It's not like power apps trigger needs to be accessed without an authenticated user. Only PowerApps application can call this flow, and all power apps applications are Microsoft AD authenticated users. Isn't Power Apps marketed to be used in tandem with flow? All Microsoft needs is to is validate the call via authentication router and send the user context to the trigger input. The user has already authenticated from power apps anyway.
This is a major security issue, making power apps + power automate, in my opinion, open to attacks. So if you have a PowerApp that is available to the entire organization, you are most definitely widely open to attacks and have to be aware that all data that a flow returns to powerapps is accessible to every user of your application. In my case, all employees of the organization have the ability to attack.
The only workaround I see, is creating a custom PCF component that reads the GraphAPI key from browser's local storage and pass it along with the request to flow trigger. Then in the flow, I make a GraphAPI get request to an endpoint with that token and see if that fails with a forbidden error, and only proceed if doesn't. Although it's a solution, it's an ugly and terrible solution to a problem that should be fixable very easily by Microsoft.
If I missed something, or If someone has a better solution, I'd like to know.
Conclusion
Need PowerApps trigger v3 that provides user context information of the calling user from power apps.
@neerajsu wow this is interesting, but I don't know how to fix this. Following this post
The first Microsoft-sponsored Power Platform Conference is coming in September. 100+ speakers, 150+ sessions, and what's new and next for Power Platform.
Announcing a new way to share your feedback with the Power Automate Team.
Learn to digitize and optimize business processes and connect all your applications to share data in real time.
User | Count |
---|---|
42 | |
17 | |
16 | |
15 | |
13 |
User | Count |
---|---|
67 | |
36 | |
27 | |
20 | |
17 |