Connect and authenticate to data sources
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 build by a power user might need to include data coming from Microsoft Dataverse and data from another source like a SQL data base or some other location.
Connecting and authenticating to a data source is done separately from authenticating to a Power Platform service. When looking at how connection authentication is done, you first need to understand how Power Platform services connect with different data sources. Depending on the data source, Power Platform services connect in various ways, however the general pattern is the same. Based on the app and the data source that is being used, the authentication credentials used may be the same as 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 the need for a separate connector. Canvas apps store consent 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 that are direct to Dataverse. Both Power Apps and Power Automate support legacy connectors that access Dataverse using connectors such as the now deprecated Dynamics 365 connector and the Microsoft Dataverse (legacy) connector.
The diagram below illustrates how canvas apps work with Dataverse.
Power Apps back-end services request data directly from Dataverse.
Dataverse returns query results back to Power Apps back-end services.
Connecting to non-Dataverse data sources
In general, Power Platform services will use connectors to work with external data sources that aren't Dataverse. These connectors act as API wrappers that help to provide access to data and commands that will be available through the connector.
The following diagram illustrates a typical pathway using an Azure API Management (APIM) connector.
The Power Platform service sends a connection request to the Power Apps Resource Provider (RP).
The Power Apps RP asks the API Hub to create a connection and store the authentication credentials.
The Power Platform service sends a data query request to the API Management connector.
The API Management connector sends a request to the consent service to get permission to access the data source.
The consent service returns credentials to the API Management connector.
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.
The API Management connector passes the data query to the external connector.
The connector sends the query to the data source.
The data source returns the requested data to the connector.
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 credentials the connector requires. 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 you use 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.