Completely isolating Microsoft.Graph.Authentication solving dependency issues

[Stephan van Rooij (svrooij)]

Changes proposed in this pull request

• Isolating Microsoft.Graph.Authentication dll to not have any external dependencies, moved to core
• Create AssemblyLoadContext for PS7+ and load .Core with all dependencies there
• Zero dependencies are leaked into the Default AssemblyLoadContext as verified by a test loading a conflicting Microsoft.Identity.Client version there.

Other links

• Inspired by my latest project PowerShellRepackager
• Thanks to Vincent Biret (@baywet) for poking me in this linkedin comment
• Gavin Barron (@gavinbarron) here is the pr you asked for 😄
• ... (various links to people complaining about dependency issues with Microsoft.Graph.Authentication)

[Ramses Sanchez-Hernandez (ramsessanchez)]

Thank you Stephan van Rooij (@svrooij) , this is amazing restructuring to achieve full isolation.

approving, passed on test build #3791

[Mike Crowley (Mike-Crowley)]

A consideration for the release notes, since the PR description doesn't mention it: once the auth engine and its dependencies load into the private context, PowerShell scripts on PS7 can no longer reference the module's internal .NET types by name. Two common patterns break:

• [Microsoft.Graph.PowerShell.Authentication.GraphSession]::Instance (how scripts pull the raw access token out of the session, since Get-MgContext doesn't expose it)
• catch [Microsoft.Graph.PowerShell.AuthenticationException] (this PR had to rewrite that same catch in its own Permissions.ps1)

The Loader README documents this, but a breaking-change note would head off a wave of "type not found" issues.

[Michael Morten Sonne | Microsoft MVP (michaelmsonne)]

On time - so nice to see Stephan van Rooij (@svrooij) ! 🙏

[Stephan van Rooij (svrooij)]

A consideration for the release notes, since the PR description doesn't mention it: once the auth engine and its dependencies load into the private context, PowerShell scripts on PS7 can no longer reference the module's internal .NET types by name. Two common patterns break:

• [Microsoft.Graph.PowerShell.Authentication.GraphSession]::Instance (how scripts pull the raw access token out of the session, since Get-MgContext doesn't expose it)
• catch [Microsoft.Graph.PowerShell.AuthenticationException] (this PR had to rewrite that same catch in its own Permissions.ps1)

The Loader README documents this, but a breaking-change note would head off a wave of "type not found" issues.

Ramses Sanchez-Hernandez (@ramsessanchez) it seems people were using undocumented features that were possible because of the dlls leaking to the default assembly context. The exception might need a decent sample, shall I create a separate issue for the pull raw access token from session use-case?

#securityhat -> Should the get raw access token command be protected somehow? I would say an opt-in that has to be set together with Connect-MgGraph something like -AllowAccessToAccessToken together with the login.

And then a Get-MgAccessToken [-Scopes ....] to get an access token as a secure string that checks wehter or not you've set the -AllowAccessToAccessToken upon connecting.

[Mike Crowley (Mike-Crowley)]

Stephan van Rooij (@svrooij) thanks! I'd skip the connect-time opt-in though. It doesn't really protect anything, since code in the same session can already grab the token without touching any internal types: Invoke-MgGraphRequest -OutputType HttpResponseMessage, then .RequestMessage.Headers.Authorization.Parameter. That should keep working after this PR, because the loader hands every shared-framework assembly (System.Net.Http included) back to the default context. Not tested against a build yet, since none has shipped. On top of that, the Loader README already points at reflection for the private types, and anything running in the session can just call Graph itself.

The realistic risk is a token landing in a log or a transcript, and a Get-MgAccessToken that returns a SecureString covers that on its own. That's what Az.Accounts 5.0 did with Get-AzAccessToken. Ideally it ships in the same release as this PR, so the notes can say "use this instead" and not just "this broke."

Two more things that might be worth a line in the notes:

• Tools that inject a token by building AuthContext / GraphSession themselves (AADInternals does this) can switch to Connect-MgGraph -AccessToken.
• For the exception, the same type-name match this PR uses in Permissions.ps1 makes a decent sample: catch { if ($_.Exception.GetType().FullName -eq 'Microsoft.Graph.PowerShell.AuthenticationException') { ... } }

🤖 Drafted and posted by Claude (Claude Code) on behalf of Mike Crowley (@Mike-Crowley).