{"id":16345,"date":"2021-09-10T17:24:25","date_gmt":"2021-09-11T00:24:25","guid":{"rendered":"https:\/\/www.microsoft.com\/en-us\/power-platform\/blog\/power-apps\/best-security-practices-for-power-apps\/"},"modified":"2021-09-10T17:24:25","modified_gmt":"2021-09-11T00:24:25","slug":"best-security-practices-for-power-apps","status":"publish","type":"power-apps","link":"https:\/\/www.microsoft.com\/en-us\/power-platform\/blog\/power-apps\/best-security-practices-for-power-apps\/","title":{"rendered":"Best security practices for Power Apps"},"content":{"rendered":"
We get questions from time to time about how our customers should work securely with Power Apps.\u00a0 Security and privacy are very important to us.\u00a0 For the most control over both security and privacy we recommend Dataverse which has best in class security and privacy features.<\/p>\n
However, customers may not have their data in Dataverse.\u00a0 \u00a0And, it’s important for customers to be able to connect to data where it lives.\u00a0 Power Apps enables this scenario with a very rich set of connectors.\u00a0 \u00a0As 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.<\/p>\n
We talk about connections being “implicitly” or “explicitly” shared.\u00a0 \u00a0By this we mean that the authentication method used for the connection is either\u00a0explicit<\/strong>\u00a0or\u00a0implicit<\/strong>.<\/p>\n An\u00a0explicitly shared connection<\/strong>\u00a0means 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\u2019t even notice when the authentication takes place.<\/p>\n Explicitly shared connections are the most secure.\u00a0 \u00a0Explicitly shared connections use the user’s ID on the server to authenticate and then formulates the queries (e.g., filtering, etc.) on the server.\u00a0 \u00a0For 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\u00a0row level security<\/a>\u00a0for rows, and the\u00a0deny<\/a>\u00a0permissions 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.<\/p>\n An\u00a0implicitly shared connection<\/strong>\u00a0means 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\u2019s credentials are\u00a0not<\/strong>\u00a0used to authenticate. Each time the end user runs the app, they’re using the credentials the author created the app with.<\/p>\n An implicitly shared connection is the least secure.\u00a0 It has the all of the risks associated with a connection made directly to a server on a service.\u00a0 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.\u00a0 Consequently, we actively discourage the use of implicitly shared connections except in narrow scenarios where the data and access are already public.\u00a0 \u00a0If you have a connection of this type we encourage you to consider a more secure connection type.<\/p>\n Some data sources (such as SQL Server) have multiple ways in which you can connect.\u00a0 \u00a0For example, the following four connection authentication types can be used with SQL Server for Power Apps:<\/p>\nConnection choices.<\/h2>\n