how secure are your power apps - everything you need to know

As Microsoft Power Apps is becoming a disruptive technology app leader within organisations, how are you staying on top of the security layer and model. We'll share with you the different options and what to look for when deploying your apps.

Overview

We get questions from time to time about how our Power Apps work securely within a customer Microsoft Tenant. Firstly security and privacy are very important to us.  For the most control over both security and privacy we recommend always leveraging Microsoft Dataverse. It has best in class security and privacy features, and we'll share with you why and how..

We also however know that not every customer has Dataverse as an option and, it’s important for customers to be able to connect to data where it lives.  Power Apps enables this scenario with a very rich set of connectors.   As part of the deployment of your app, however, you should be clear about the security risk for how authentication to data is enabled for your app.

We talk about connections being “implicitly” or “explicitly” shared.   By this we mean that the authentication method used for the connection is either explicit or implicit. Lets look at the differences, between both options.

An explicitly shared connection means that the end user of the application must authenticate to the back-end data source (e.g., SQL Server) with their own explicit credentials. Usually this authentication happens behind the scenes as part of Azure Active Directory or Windows authentication handshake. The user doesn’t even notice when the authentication takes place.

Explicitly shared connections are the most secure.   Explicitly shared connections use the user’s ID on the server to authenticate and then formulates the queries (e.g., filtering, etc.) on the server.   For instance, to securely filter data on the server side for SQL Server, such an app uses built-in security features in SQL Server such as row level security for rows, and the deny permissions to specific objects (such as columns) to specific users. This approach will use the Azure AD user identity to filter the data on the server.

An implicitly shared connection means that the user implicitly uses the credentials of the account that the app maker used to connect and authenticate to the data source during while creating the app. The end user’s credentials are not used to authenticate. Each time the end user runs the app, they’re using the credentials the author created the app with.

An implicitly shared connection is the least secure.  It has the all of the risks associated with a connection made directly to a server on a service.  In particular, you cannot rely on filtering commands to be be secure and even the name of the database and other details can be discovered. 

Consequently, we actively discourage the use of implicitly shared connections except in narrow scenarios where the data and access are already public.   If you have a connection of this type we encourage you to consider a more secure connection type.

Connection choices.

Some data sources (such as SQL Server) have multiple ways in which you can connect.   For example, the following four connection authentication types can be used with SQL Server for Power Apps:

Conclusion

If your engaging a vendor, third party or contract to build your Power App, our recommendation is to ask the above security connections questions. It may shape and or change your decision. You may discover vendor apps, have links or IFrames, and require SQL Azure Servers where your data is exposed. Ask for the architecture document and how they secure your data.

To read more about Microsoft Dataverse Security check out the Microsoft Link Below.

Looking to chat to a Microsoft Power App Architect? get in touch with us at hello@thedigitalproject.com.au and we'll set up a meeting.

https://docs.microsoft.com/en-us/power-platform/admin/wp-security?msclkid=3f94b53ecf4c11ecb7f928dfdaeb688e