Best security practices for Power Apps
Best practices for securely using external data sources with Power Apps
We get questions from time to time about how our customers should work securely with Power Apps. Security and privacy are very important to us. For the most control over both security and privacy we recommend Dataverse which has best in class security and privacy features.
However, customers may not have their data in Dataverse. 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.
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:
| Authentication Type | Power Apps connection method |
|---|---|
| Azure AD Integrated | Explicit |
| SQL Server Authentication | Implicit |
| Windows Authentication | Implicit |
| Windows Authentication (non-shared) | Explicit |
Future
We are always looking to improve our product and welcome feedback you may have.
