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.
Scenario:
Lets say I have a power automate flow with the following features/requirements:
- I have a flow that provides user meta data and user specific information for a user.
- To achieve this, I require the username/email as input, to pull this information from somewhere (Let's say some database)
- This is because meta data is sensitive to each user. Meaning a users shouldn't have access to some other user's information
Lets say I have a power app with the following features/requirements:
- For the logged in user I want to show his/her user specific information
- I also want to allow the user to edit and save this information
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
- Open power apps.
- Open the developer tools (F12). Look at the network tab.
- Do the action which retrieves/updates information from power apps UI.
- You should see a Http call going to something like (https://unitedstates-002.azure-apim.net/invoke).
- Right click the call and copy as curl.
- Open postman and import the curl command. Notice the Body in the post request.
- Now you can just change the request body to whatever email you like. In this scenario, the post body would be something like {"VarEmailID_Value":"someuser@somedomain.com"}
- Voila, now you can retrieve any persons information and even change it as you wish (In this scenario)
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 use this, and all power apps applications are Microsoft authenticated users. Isn't Power Apps marketed to be used in tandem with flow? All Microsoft needs is to, send the call via authentication router and send the user context to the trigger. The user has already authenticated from power apps anyway.
This is a major security issue, making power apps + power automate, in my opinion, unsecure 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 ensure that you don't send any secure data that is being retrieved from power apps. You have to assume that all employees have access to anything that the backend flow can provide.
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.
