Authentication Broker sign-in fails locally on macOS 26 with "Invalid source app" (public cloud, ZIP install to ~/Applications)

Commencez par les étapes de reproduction de l’installation ZIP et la sortie de main.log sous ~/Library/Logs/StorageExplorer, puis comparez le comportement du broker avec l’investigation associée dans #9045. Vérifiez le paramètre application.signIn.signInUsing dans settings.json et validez le contournement via le navigateur système ; le travail est terminé lorsque la connexion au broker réussit ou que son échec produit un fallback clair ou une erreur exploitable.

• I have installed the latest version of Storage Explorer.
• I have checked existing resources, including the troubleshooting guide and the release notes.
• I have searched for similar issues.

Storage Explorer Version

1.45.0

Regression From

Not a regression (first observed on this machine with 1.45.0; Authentication Broker has been the macOS default since 1.43.0)

Architecture

arm64

Storage Explorer Build Number

20260730.9

Platform

macOS

OS Version

macOS 26.5.2 (25F84), Apple Silicon

Bug Description

Sign-in via Authentication Broker fails 100% of the time against the public Azure cloud on macOS 26.5.2. The broker rejects the call with a redirect-URI scheme validation error, and no AADSTS code is produced:

Unable to sign in: Unknown Status: Unexpected
Error: 0xffffffffffff5bf0
Context: Description: Error Domain=MSALErrorDomain Code=-50000 "(null)" UserInfo={MSALErrorDescriptionKey=MSAL redirectUri validation error: redirect uri has incorrect scheme - it must be in the form of msauth.<app_bundle_id>://auth
ADAL redirectUri validation error: Source application does not match redirect uri host. Invalid source app., MSALInternalErrorCodeKey=-42000, MSALBrokerVersionKey=5.2602.0}, Domain: MSALErrorDomain.Error was thrown in sourceArea: Broker
Tag: 0x1e5136c4 (error code -42000) (internal error code 508638916)

From ~/Library/Logs/StorageExplorer/<session>/*_main_*.log:

<ERRO> Failed to addAccount, authFlowType: authBroker, authResult: {"Account":null,"UserCancelled":false,...
  "ExceptionType":"Microsoft.Identity.Client.MsalServiceException",
  "ExceptionString":"MSAL.NetCore.4.83.1.0.MsalServiceException:\r\n\tErrorCode: unknown_broker_error
  ... at Microsoft.Identity.Client.Platforms.Features.RuntimeBroker.WamAdapters.HandleResponse(...)
  ... at Microsoft.Identity.Client.Platforms.Features.RuntimeBroker.RuntimeBroker.SignInInteractivelyAsync(...)

This affects both addAccount (fresh sign-in) and reauthAccount (re-auth of a cached account), and it survives Help → Reset.

This appears to be the public-cloud counterpart of the second issue tracked in #9045 — the one @craxal described as "investigating why the broker is falling back to the unsignedapp redirect", consistent with the later note: "It seems the redirect should normally have the bundle ID. If it's not there, MSAL falls back to the unsigned redirect." In both cases the broker fails to derive a valid msauth.<bundle_id>://auth redirect URI. The difference in where it fails may be the most useful signal here:

	#9045	This report
Install method	PKG installer	ZIP extraction (StorageExplorer-darwin-arm64.zip)
Install location	/Applications	~/Applications
Cloud	Azure China	Azure public
Failure point	Reaches Entra → AADSTS50011 with msauth.com.msauth.unsignedapp://auth/	Rejected by the broker, no AADSTS code

Both bundles ship the identical, correctly-signed com.microsoft.StorageExplorer app, so the differing failure points point at install method and/or install location as the variable that determines whether the broker can resolve the caller's identity at all. Answering the question @craxal raised in #9045: this machine used the ZIP, not the PKG — and the ZIP is an officially published release artifact, so if broker sign-in is only supported for PKG-installed copies, that deserves either documentation or a detectable, actionable error.

MSALBrokerVersionKey=5.2602.0 matches the installed Company Portal 5.2602.0 exactly, confirming which broker is servicing the request. The device is Intune-managed with Platform SSO enabled.

Resource Types

No response

Authentication Method

Sign in

Connection Type

Sign in (subscription)

Steps to Reproduce

1. On macOS 26.5.2 (arm64), install Storage Explorer 1.45.0 by extracting StorageExplorer-darwin-arm64.zip and placing the .app bundle in ~/Applications.
2. Remove the quarantine attribute so the app is not App-Translocated: xattr -dr com.apple.quarantine "~/Applications/Microsoft Azure Storage Explorer.app".
3. Launch Storage Explorer. Leave "Sign in with" at its default (Authentication Broker).
4. Open the Connect dialog → Subscription → Azure (public cloud) → Next.
5. Attempt to sign in with a work account.

Actual Experience

Sign-in fails immediately with the MSALErrorDomain / Invalid source app error above. No browser window or broker UI is ever presented. Retrying, and resetting via Help → Reset, make no difference.

Expected Experience

Sign-in succeeds, or the broker's inability to resolve the app's identity is detected and Storage Explorer transparently falls back to the system-browser flow rather than dead-ending on unknown_broker_error.

Additional Context

Workaround. Moving off the broker resolves it completely — sign-in then succeeds on the first attempt:

// ~/Library/Application Support/StorageExplorer/settings.json
{
  "application.signIn.signInUsing": "systemBrowser"
}

Equivalently, Settings → Sign in → "Sign in with" → system browser. Worth flagging for anyone else debugging this: application.* settings live in settings.json, not in config.json in the same directory. Writing the key into config.json is silently ignored and the app keeps logging authFlowType: authBroker, which makes the workaround look like it failed.

Ruled out — App Translocation. The bundle was initially quarantined and launched from ~/Downloads, so macOS ran it from /private/var/folders/.../AppTranslocation/<uuid>/d/…. That was corrected: bundle moved to ~/Applications, com.apple.quarantine stripped, re-registered via lsregister -f, and ps confirmed the process running from the real path. The broker error is byte-for-byte identical before and after, so translocation is not the cause.

Code signature is intact:

Identifier=com.microsoft.StorageExplorer
TeamIdentifier=UBF8T346G9
Authority=Developer ID Application: Microsoft Corporation (UBF8T346G9)
CodeDirectory v=20500 size=649 flags=0x10000(runtime)
$ codesign --verify --strict "~/Applications/Microsoft Azure Storage Explorer.app"   # passes

Could not be tested: the account on this managed device is not in the admin group, so /Applications is not writable and the PKG installer cannot be run. That unfortunately leaves install method and install location confounded in this report — happy to test either if someone can suggest a way to do it without admin rights.

Probably unrelated, noting only for completeness: the shipped Info.plist declares a single URL scheme, with no msauth.com.microsoft.StorageExplorer entry:

CFBundleURLTypes → CFBundleURLName = com.microsoft.StorageExplorer
                   CFBundleURLSchemes = ( storageexplorer )

We initially suspected this, but #9045's PKG-installed reporter has the same Info.plist and still reached Entra, so a missing CFBundleURLSchemes entry does not by itself explain the local rejection — mentioning it only so it can be dismissed rather than re-investigated.

Happy to run further diagnostics or attach full logs on request.