Connect and authenticate to data sources

Completed

Many of the applications and solutions that you build on the Power Platform will require data from other data sources. For example, a canvas application might need to include data from Microsoft Dataverse and from another source, like an SQL data base or other source.

Connecting and authenticating for a data source is done separately from authenticating for a Power Platform service. When considering how connections authenticate, you first need to understand how Power Platform services connect with different data sources. Power Platform services connect in various ways depending on the data source. Based on the app and the data source being used, the authentication credentials for the data source may be the same as for the Power Platform service or they may be different.

Connecting to Microsoft Dataverse

Power Apps canvas and model-driven apps connect directly to Dataverse without needing a separate connector. Canvas apps store the permission to work with other Dataverse environments in the Power Apps Resource Provider (RP). Power Automate authenticates using an API Hub, but all data interactions after authentication are direct to Dataverse. Both Power Apps and Power Automate support legacy connectors for accessing Dataverse, including the deprecated Dynamics 365 connector and the Microsoft Dataverse (legacy) connector.

The diagram below illustrates how canvas apps work with Dataverse.

Diagram of the direct connection between the Power Apps back-end cluster and Dataverse.

  1. Power Apps back-end services request data directly from Dataverse.

  2. Dataverse returns query results back to Power Apps back-end services.

Connecting to non-Dataverse data sources

In general, Power Platform services use connectors to work with external data sources that aren't Dataverse. These connectors act as API wrappers to help to provide access to the data and commands available through the connector.

The following diagram illustrates a typical pathway using an Azure API Management (APIM) connector.

Diagram of the Power Platform back-end services working with an API Hub/API Management connector to reach external data connectors.

  1. The Power Platform service sends a connection request to the Power Apps Resource Provider (RP).

  2. The Power Apps RP asks the API Hub to create a connection and store the authentication credentials.

  3. The Power Platform service sends a data query request to the API Management connector.

  4. The API Management connector sends a request to the consent service to get permission to access the data source.

  5. The consent service returns credentials to the API Management connector.

  6. The API Management connector sends the consent credentials to the Power Apps RP. The credentials are stored in the RP so that Power Apps doesn't prompt for consent again the next time data is requested.

  7. The API Management connector passes the data query to the external connector.

  8. The connector sends the query to the data source.

  9. The data source returns the requested data to the connector.

  10. The connector passes the data back to the Power Platform back-end cluster.

Authenticating to data sources

Users authenticate to the Power Platform service first. Then, separately, users authenticate to a data source using the connector's required credentials. The API Hub credentials service always stores and manages credentials.

Some connectors support more than one authentication method. Authentication to a data source is specific to that data source instance. It's based on the authentication method the maker chose when creating the connection.

There are two types of data source authentication methods in Power Apps:

  • Explicit authentication means the app user's credentials are used to access the data source.

  • Implicit authentication means the credentials the app maker provided when creating the connection are used.

We recommend using explicit authentication whenever possible. It's more secure.

You can learn more about the difference between explicit and implicit connections here: Explicit vs implicit connections. Although the article refers to SQL Server, it applies to all relational databases.