Implicitly shared connections in Power Apps: what’s the risk?

When you are using Power Apps canvas apps to connect to most Microsoft services, the users will be shown the connection consent dialog. Here the user is requested to approve that the canvas app is allowed to use their identity when connecting to services like SharePoint, Microsoft Teams, Outlook, and so on.

While these prompts may be perceived as a bit of a nuisance by the users, they are actually a good sign: the app is using the identity and privileges of the current user when reading and writing data. This isn’t always the case with connectors, especially third-party SaaS services without OAuth support.

What you as an app maker or a Power Platform administrator need to be aware of is the two different authentication methods that apps or flows may use when connecting to data sources. A common example is the SQL Server connector that may use either an explicit or implicit authentication. Explicit is the safe and preferred option, yet it may not always be available. When using the implicit option, you should read what the Microsoft documentation says about this:

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.

What does this mean in practice? In short, the identity is hardcoded into the connection. Every user reads and writes data by using the same identity. Which often will have fairly broad access rights into the target system, given that it needs to serve the needs of every possible app user. In the worst case, the app maker has sysadmin level access and these credentials are then used for relaying calls from all different users.

Hold on, we’re not exactly giving away the user name and password to the app users. They can only see data via the app UI and perform the actions via the buttons we provide. So, is there any real risk in using shared credentials or is this just generic best practices talk?

The real risk arises from a scenario where the app users are also app makers in the environment where the original app is running. When the app is shared, the credentials are also implicitly shared as part of the connection used by the app. If they have the Environment Maker security role, this means they can use that connection in a new app they create themselves. Meaning: whatever the original app maker could do via the connector, these users are technically able to do as well. UI level security measures in the original app become void as the user can design a different UI around the same connection credentials.

To illustrate how a connector that uses implicit credentials (API keys, user/pwd, client/secret) behaves in a Power Platform environment, let’s walk through a few scenarios and test this thing in practice.

Building an app

We’ll use the Bing Maps connector in our demo app, since the authentication model in it is based on a simple API key. This key is punched in when the app maker creates a new connection:

We create this connection with the user account “FF Admin” who has environment maker level access to the environment. Later we’ll test what the implications are for other user accounts with different privileges.

We’re not going to build a very fancy app, just a quick demo that uses 2 actions in the Bing Maps connector. GetLocationByAddress retrieves the latitude and longitude based on the address fields the user fills in the app. GetMapV2 then uses these coordinates as parameters to pull an image of the said location from a satellite map.

Now it’s time to share the app to another user: “FF App Maker”. In that sharing dialog Power Apps is showing a warning to us: “Sharing this app implicitly shares at least one connection. Implicitly shared connections are shared with the same audience as the app. Shared connections can be used to access the datasource outside of this app.”

While the warning looks somewhat scary, what are we going to do at this point? If we have to use a data source that uses such implicitly shared connectors, we can only click “Confirm” and proceed with our demo scenario. Many app makers may not realize what the risks are and just treat it as yet another banner to close and ignore.

Using a connection from another user’s app

We now log in with the “FF App Maker” identity and see from our mailbox that there’s a cool new app waiting to be launched:

The app looks interesting to us, so we start to wonder “hmm, could we leverage this same connector in more scenarios?” We happen to have the Environment Maker level rights in this environment (this is the important bit!), so we can open the Power Apps Maker portal and explore the possibilities. Upon opening the Connections menu in the environment, we see the Bing Maps connection from FF Admin user:

We decide that this connector would be very useful also in an app that’s designed for the phone screen. So, we create a brand new app and add the existing Bing Maps connection to it. There are no questions for API keys, as the connection is already configured and ready for use. We can therefore include it in our new app called “Bing Maps on the go” and use any action available in the connector. Cool!

Now that our new phone app is ready, let’s go and share it with yet another user. “FF App User” is a user account that does not have any Environment Maker rights in the environment we built our app in. “FF App Maker” (the second app’s creator) can still share the new app to this user via the standard Power Apps share dialog.

However, when “FF App User” gets the email and clicks on the link to launch the app, the connection consent dialog presents a problem. The “Allow” button is grayed out. Instead, we see the text “this app needs access to this connection” next to the Bing Maps icon.

Clicking on the “ask for access” link launches a new draft email message, including template text. “Hi, I need you to share the Bing Maps connection so I can use the app…”

“FF App Maker”, the owner of the new app, receives our message requesting the Bing Maps connection to be shared. Upon opening the list of connections in the environment and clicking on “share”, the dialog here is grayed out, too.

Because “FF App Maker” had only received the “can use” permission when “FF Admin” shared his original app and connection, giving further permissions to new users isn’t possible. While our maker persona is able to use all the objects within the environment to build new apps, passing on the rights to these objects for other users isn’t possible anymore. That’s where ownership would be needed instead.

Let’s imagine that the “FF Admin” user has now become aware of the problem related to the implicitly shared connection in this environment that has several other Environment Makers. If he unshares the original app, what happens to the connections related to it? The answer is: the connection remains shared to the users.

The reason for this behaviour is presumably the many-to-many relationship of connections and apps. How would the system know that the same connection wouldn’t have been also shared to the user via some other app? Or shared directly outside the app? Such relationships are probably not stored in the platform, which means implicit sharing of connections via apps cannot be undone by revoking app level access alone.

Considerations for connectors with stored credentials

We’ve learned that unless an app user always authenticates explicitly into the connectors by using his or her own credentials, there’s a real risk of accidentally giving away more access rights than intended. The warning dialog presented upon app sharing about implicit connections is too little, too late. These issues need to be considered already when drafting your Power Platform environment strategy.

You should be especially careful with implicit sharing in your tenant’s Default environment. Why? Because every licensed user (Office 365 or more) in your organization is going to have Environment Maker permissions there. You cannot remove these rights, it’s by design. So, by using any connectors with implicit sharing in the Default environment you are essentially handing out the keys to the data to any user of your Power App.

There can be perfectly valid reasons for using connectors that rely on stored credentials like API keys when building Power Platform solutions. You don’t need to block them altogether, rather you should enforce a governance policy in which they are only used in dedicated environments without broad access to Environment Maker rights. The maker or the app should build it in a development environment, then the app’s services should be consumed by app end users in a production environment with a limited number of makers/admins. DLP policies should then be put in place to block such connectors from the Default environment. (Don’t forget custom connectors to systems that might use basic authentication / API keys instead of modern OAuth 2.0.)

The real danger with connectors that use an API key, client/secret or other type of stored credentials is that environment makers get unlimited access to all the connector capabilities. In our simple demo app the issue could be in consuming Bing Maps API calls in ways that are not intended, which may not be that big of a deal. Yet what if you’ve built an app on top of a critical business system and used the connector to provide read-only access to its data in the app UI? Another app maker in the same environment could use the same connection to not just read records, but also create, update – even delete.

A while ago when I was taking a demo screenshot of an application with an implicitly shared SQL Server connection in the Default environment of one of our customers (not an app built by our team), I got really nervous. For purely illustration purposes, I created a blank app, added the connection, added a button, set its OnSelect action to “Remove(TableName, Gallery1.Selected…” Oh s***!😬 What if the user account has delete rights on the SQL table and I now accidentally click this button in the demo app?!?

UI level access management ain’t enough

As general guidance to any app makers who are relying on the canvas app screens and Power Fx formulas to show/hide data and actions based on the identity of the current user: ensure you’re not using connectors with implicit sharing. If you are, pay special attention to the Power Platform environment in which you distribute the app and how it’s security roles are managed.

In general, implementing access control features only on the client side is not a great idea. You can take a look at the “God Mode” concept from the Power Apps model-driven apps world for reference. If the app end user can bypass the security model by installing a browser extension or just copy-pasting a piece of JavaScript into the browser console – did you ever really have a security model in place?

In short: if the users are able to modify the object which determines the actions available to them in the app, escalation of privileges will be easy. Whether manipulating the code running locally on the browser or creating a new app to leverage implicitly shared connections, doors like this should not be left open even in internally facing applications.

Interested in reading our latest Power Platform blog posts?

You’re welcome to subscribe to our email newsletter: Forward Forever Monthly. Max 1 email per month, with a curated list of latest insights and articles on Power Apps, Power Automate, Power BI.

Leave a Reply