[Bug] [Question] Unable to use MSAL browser auth (Graph API) in Code Apps — dynamic iframe URL prevents redirect URI registration

[LeHailender]

Describe the bug

Power Apps Code Apps run inside a sandboxed iframe with a dynamic URL that changes on every deployment:

https://.environment.api.powerplatformusercontent.com/.../storageproxy//index.html

The storageproxy segment includes a timestamp (e.g., 20260318t164616z4f80d73c36) that changes with each pac code push. This makes it impossible to register a stable redirect URI in Azure AD App Registration for browser-based MSAL authentication flows.

Why this is a problem

Any Code App that needs to call Microsoft Graph API (e.g., SharePoint files, user photos, Teams presence) with delegated permissions requires browser-based MSAL authentication. Since no MSAL flow (redirect, popup, or custom window) can work with the dynamic iframe URL, Code Apps cannot authenticate to Graph API when running in Power Platform.

The same app works perfectly in local development (http://localhost:5173) because the URL is stable and can be registered.

What we tried

• acquireTokenRedirect with window.location.origin as redirect URI

Result: origin/ returns RouteNotFound — the Power Platform host only serves the app at the full dynamic path, not at the origin root.

• acquireTokenPopup with window.location.origin as redirect URI

Result: The popup lands on the RouteNotFound JSON error page. MSAL cannot process the auth callback because no JavaScript runs on that page.

• acquireTokenPopup with https://apps.powerapps.com as redirect URI

Result: The popup lands on apps.powerapps.com, which redirects to make.powerapps.com — a cross-origin page. MSAL cannot communicate back to the parent window via window.opener.

• Custom auth window opening the full app URL with ?auth=sharepoint

Result: RouteNotFound — the Power Platform API host rejects any query parameters it doesn't recognize on its routes.

• Wildcard redirect URI registration

Result: Azure AD does not allow wildcard characters in SPA redirect URIs.

Expected behavior

Code Apps should provide one of the following:

1. A stable redirect URI (e.g., https://.environment.api.powerplatformusercontent.com/auth/callback) that can be registered in Azure AD and serves a minimal page that MSAL can process
2. A built-in token acquisition API in the Code Apps SDK (e.g., getContext().acquireTokenForResource('https://graph.microsoft.com', scopes)) that leverages the existing Power Platform SSO session
3. . Support for custom connectors or fetch with delegated auth from within Code Apps

Environment

• PAC CLI: 2.4.1
• @microsoft/power-apps SDK: 1.0.3
• @azure/msal-browser: 5.4.0
• Framework: React 19 + Vite
• Browser: Edge/Chrome

Minimal reproduction

1. Create a Code App with pac code init
2. Add @azure/msal-browser and configure a PublicClientApplication
3. Register an Azure AD app with Graph API scopes
4. Try any MSAL flow (acquireTokenPopup, acquireTokenRedirect)
5. Run locally → ✅ works
6. pac code push and run in Power Platform → ❌ fails

[eschavez]

@LeHailender - This is not something we support. The recommended approach is to use a custom connector. Custom connectors are supported today in code apps. Please give that a try and let us know if you have any questions

[MYMaj]

Unfortunately, the custom connector is not compatible with the SharePoint file upload functionality. After one year and still cannot work with one of the most important feature. You should work on this ASAP

[GBency]

Hi everyone,
I’d like to clarify and expand on the solution I eventually adopted, as the separation of responsibilities between connectors is an important part of what made this work.
Initial approach (MSAL)
I initially went down the MSAL path and managed to get everything working correctly using ssoSilent inside an iframe.
This allowed me to acquire tokens and successfully call both Power Automate and SharePoint Online APIs.
This solution works perfectly when the app runs as a Web app, but it does not work reliably in Teams Desktop, where iframe-based silent authentication introduces limitations that are hard to mitigate.
The working architecture
At that point, I changed my approach and focused on Power Platform connectors, splitting responsibilities clearly:

1. Custom Connector → Power Automate

The Custom Connector is used exclusively to handle authenticated calls from the Code App to Power Automate Flows
The flows are triggered via HTTP Request, and authentication is managed at connector level
This removes the need to pass or manage tokens in the frontend

2. HTTP with Microsoft Entra ID (preauthorized) → SharePoint Online

The HTTP with Microsoft Entra ID (preauthorized) connector is used specifically to connect to SharePoint Online
Through this connector, the app can safely:

Call SharePoint REST APIs
Upload files
Perform operations under Entra ID–controlled permissions

This works consistently in Web and Teams Desktop

This separation made the overall solution much more robust and aligned with Power Platform security principles.
Current limitation I’ve found
One limitation I haven’t yet found a good solution for is scoping:

I haven’t figured out how to configure multiple “HTTP with Microsoft Entra ID (preauthorized)” connections with different scopes
Ideally, I’d like to restrict this connector to only the scopes required for specific SharePoint operations, instead of using a broader permission set. @eschavez do you know how I can do this?

If anyone has found a way to manage multiple preauthorized HTTP connections with different scopes, I’d be very interested to learn more.
Key takeaway
What I’ve learned is that connectors are the real cornerstone, especially for Power Apps Code Apps targeting Teams Desktop.
Unfortunately, this approach is still not well documented, which makes it non-obvious compared to MSAL-based solutions.
This final solution was inspired by this video (highly recommended):
👉 https://www.youtube.com/watch?v=6MPrCp-oGas
Hopefully this helps others who are hitting the same wall with authentication in Teams Desktop.