Power Platform Community Forum Thread Details

Hi all,

I’m working on a Model-Driven App (Dynamics/Power Apps) integration where we want to show an external web application inside the Power Apps mobile app shell (without opening an external browser).

However, based on Microsoft documentation, we are seeing several constraints:

MSAL redirects are not supported inside iframes
https://learn.microsoft.com/en-us/entra/msal/javascript/browser/iframe-usage
Authentication inside an iframe isn’t supported in mobile clients
https://learn.microsoft.com/en-us/power-apps/maker/model-driven-apps/iframe-properties-legacy
Iframes behind authentication boundaries are not supported
https://learn.microsoft.com/en-us/power-apps/developer/model-driven-apps/web-resources

Given these documented limitations, we are trying to understand what supported or practical approaches others are using in real-world implementations.

Goal

From a record (e.g., Account/Lead), open an external web app inside the Power Apps mobile shell
Pass record context securely (record id, entity name)
Avoid session hijack / replay if a launch token leaks
Avoid opening an external browser if possible

Current technical idea (server-driven launch pattern)

User clicks a command/button in the model-driven app
We call a Dataverse Custom API server-side (identity derived from InitiatingUserId, not from client inputs)
The Custom API generates a short-lived, one-time launch token (TTL 1–5 minutes)
Mobile loads the external app inside an embedded frame (web resource / PCF hosting iframe)
Optional hardening: client-generated nonce (“bindingId”) to reduce replay risk

The external app would exchange the launch token server-side and establish a secure session.

Questions for the community

Given the documented limitations, is there any supported pattern to securely embed an authenticated external web app inside the Power Apps mobile shell?
In practice, are people:
- Moving the UI into a Custom Page or PCF, keeping only the backend external?
- Using a backend-for-frontend (BFF) style pattern?
- Using token-per-request approaches instead of cookies?
- Or ultimately opening the external app in the device browser as the only stable option?
Does it make any difference (from a mobile support or security standpoint) whether we use:
- A web resource iframe, or
- A PCF control hosting an iframe?
If staying inside the shell is mandatory, what architecture have you successfully implemented that aligns with Microsoft’s supported scenarios?

Any guidance, architectural recommendations, or practical experiences would be greatly appreciated.

Thanks in advance,
Abhishek

Categories:

Building Power Apps

General topics

HI @abhisc,

you have mapped the constraints accurately. MSAL redirects inside iframes are blocked by design, and the mobile shell compounds this because the webview does not share a session with the device browser. No workaround fully removes those constraints, but there are practical paths depending on your tolerance for trade-offs.

On your server-driven launch pattern

The approach you described is architecturally sound. Short-lived, one-time tokens generated server-side from InitiatingUserId is the right instinct. Two things worth tightening:

Bind the token to the device or session. A nonce alone helps but is not sufficient if the token travels over a network before the external app consumes it. Consider binding it to a fingerprint derived server-side at generation time.

Exchange happens server-to-server. The external app should never accept the launch token directly from the client. The client presents the token, the external app backend calls your Dataverse Custom API to validate and exchange it, then issues its own session credential. This removes the client from the trust chain.

Q1 and Q4: Supported pattern for embedding authenticated external apps in the mobile shell

There is no fully supported, documented Microsoft pattern for this. The iframe limitations you cited are real and apply in both web resource and PCF contexts on mobile. If staying inside the shell is mandatory, the closest workable architecture is:

Move as much of the external app's UI as is feasible into a PCF control. The PCF runs inside the shell natively and avoids the iframe authentication boundary entirely.

Keep the external backend as an API layer. The PCF calls authenticated endpoints using the Dataverse user's token obtained via Xrm.WebApi or a Custom API intermediary.

This is effectively the BFF pattern you mentioned, with the PCF acting as the frontend layer and your Custom API acting as the secure backend relay.

Q2: What people actually do

In practice, the options used in production are:

PCF with backend API calls (BFF pattern), no iframe. Most viable for staying in the shell.

Token-per-request with short-lived bearer tokens passed as query parameters or POST bodies, never in cookies, because cookies are unreliable across the mobile webview boundary.

External browser as the fallback. For complex external apps that cannot be replicated in PCF, opening the device browser with a short-lived deep link token is the most stable option, even if it breaks the shell experience.

Q3: Web resource iframe versus PCF hosting an iframe

From a mobile and security standpoint, PCF hosting an iframe is marginally better in that you get more control over the hosting context and lifecycle. But the underlying iframe authentication constraint is the same. Neither approach solves the MSAL redirect problem on mobile. The PCF wrapper does not grant the iframe a trusted session context.

The meaningful distinction is not web resource versus PCF. It is iframe versus no iframe. If you need authentication inside the shell on mobile, remove the iframe from the design.

Practical recommendation

If your external app is complex and owned by a third party, opening in the device browser with a server-generated, short-lived, bound launch token is the most defensible architecture today. If the external app is under your control, refactor its UI into a PCF and expose its logic as authenticated API endpoints. That is the only path that stays fully inside the shell and avoids the iframe authentication wall.

Thank you!
Proud to be a Super User!
Need more help?
Don’t forget to Accept as Solution if this guidance worked for you.
Your Like motivates me to keep helping