Remove embedded Newtonsoft.Json, migrate to System.Text.Json exclusively by Robbie-Microsoft · Pull Request #5959 · AzureAD/microsoft-authentication-library-for-dotnet

Robbie-Microsoft · 2026-04-28T20:47:29Z

Summary

Removes the embedded Newtonsoft.Json source tree from MSAL.NET and migrates all JSON serialization to System.Text.Json (STJ).

Previously, MSAL.NET bundled a private copy of Newtonsoft.Json (under the Microsoft.Identity.Json namespace) compiled directly into the assembly for all target frameworks except net8.0. This PR eliminates that dependency entirely.

Changes

Deleted

src/client/Microsoft.Identity.Client/json/ — the entire embedded Newtonsoft source tree (~100 files)

Infrastructure

SUPPORTS_SYSTEM_TEXT_JSON compile flag is now defined unconditionally for all TFMs (was previously only net8.0\netcore)
Removed HAVE_* Newtonsoft build-infra DefineConstants from the main csproj
Added System.Text.Json NuGet package reference for netstandard2.0, net462, and net472 (it is built into net8.0 and later)
The Platforms/net/ STJ helper files (JsonObjectAttribute.cs, JsonStringConverter.cs, MsalJsonSerializerContext.cs) now compile for all TFMs instead of only net8.0

Main library (~44 files)

Stripped all #if SUPPORTS_SYSTEM_TEXT_JSON / #else conditional blocks, keeping only the STJ code paths
Replaced ArrayBufferWriter<T> (unavailable pre-.NET 5) with MemoryStream in JsonHelper.cs

Platform files

Android broker files (BrokerRequest, AndroidBrokerHelper, AndroidAccountManagerBroker, AndroidBrokerInteractiveResponseHelper, AndroidContentProviderBroker): migrated from Microsoft.Identity.Json.Linq to System.Text.Json.Nodes
iOS IntuneEnrollmentIdHelper: migrated from JsonConvert.DeserializeObject to JsonSerializer.Deserialize

Tests / Lab

~18 test and lab source files migrated from Newtonsoft APIs (JObject, JToken, JsonConvert, [JsonProperty]) to STJ equivalents (JsonObject, JsonNode, JsonSerializer, [JsonPropertyName])
Newtonsoft.Json PackageReference removed from all 9 affected test/lab .csproj files
Fixed UnifiedCacheFormatTests: JSON object fields in test data files now use .ToJsonString() instead of .GetValue<string>()

Testing

All unit tests pass on both net8.0 and net48 (1910+ passing, 0 failures)
Integration tests will run via CI on this PR

…vely - Delete the embedded Newtonsoft source tree (json/ folder, ~100 files) - Define SUPPORTS_SYSTEM_TEXT_JSON unconditionally for all TFMs - Remove HAVE_* Newtonsoft build-infra defines from csproj - Add System.Text.Json NuGet package for netstandard2.0, net462, net472 - Move Platforms/net STJ helpers to compile for all TFMs - Strip all #if SUPPORTS_SYSTEM_TEXT_JSON / #else branches from ~44 source files - Migrate Android broker files from Microsoft.Identity.Json to STJ - Migrate iOS IntuneEnrollmentIdHelper from Newtonsoft to STJ - Remove Newtonsoft.Json PackageReference from all test/lab projects - Migrate ~18 test/lab files from Newtonsoft APIs to STJ equivalents - Fix ArrayBufferWriter<T> (not available pre-.NET5) with MemoryStream Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

token_response, id_token_response, at_cache_value, id_token_cache_value, rt_cache_value, account_cache_value are JSON objects in the test data files, not primitive strings. STJ's GetValue<string>() only works on leaf nodes; use ToJsonString() to serialize them as strings (matching prior Newtonsoft JToken.ToString() behavior). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Copilot wasn't able to review this pull request because it exceeds the maximum number of files (300). Try reducing the number of changed files and requesting a review from Copilot again.

bgavrilMS · 2026-04-28T20:56:31Z

Very nice, great to see this @Robbie-Microsoft

- ManagedIdentityTests.NetFwk.cs: remove #if NET8_0_OR_GREATER guard around JsonConvert.DeserializeObject; use System.Text.Json.JsonSerializer unconditionally (the NetFx project targets net48 where the #else branch compiled, but Microsoft.Identity.Json no longer exists) - AndroidBrokerHelper.cs: replace (string?) nullable cast with ?.GetValue<string>() — nullable annotation syntax requires #nullable enable context which the Android file does not have (CS8632) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

JsonSerializer.Deserialize<T>() without a JsonSerializerContext uses reflection which is incompatible with iOS Native AOT (IL3050). Add a local IntuneSerializerContext (partial JsonSerializerContext) in IntuneEnrollmentIdHelper.cs with [JsonSerializable(typeof(EnrollmentIDs))] and use the non-generic JsonSerializer.Deserialize(json, type, context) overload which is AOT-safe. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Copilot wasn't able to review this pull request because it exceeds the maximum number of files (300). Try reducing the number of changed files and requesting a review from Copilot again.

…ClaimExtractor - LabResponseHelper.Deserialize<UserConfig/AppConfig>: add PropertyNameCaseInsensitive=true to match Newtonsoft's case-insensitive ToObject<T>() behavior. Without this, Key Vault JSON properties like 'LabName'/'labName' would not deserialize into UserConfig.LabName, causing all integration tests to fail with 'lab name is not set on user'. - JwtClaimExtractor.TryExtractExpirationClaim: STJ returns JsonElement (not long) when deserializing Dictionary<string,object>. Handle JsonElement.TryGetInt64() so expiry is correctly extracted from attestation JWTs. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

gladjohn · 2026-04-28T22:04:25Z

Very nice, great to see this @Robbie-Microsoft

Agree

gladjohn · 2026-04-28T22:06:21Z

-#if SUPPORTS_SYSTEM_TEXT_JSON
 using JObject = System.Text.Json.Nodes.JsonObject;
-#else
-using Microsoft.Identity.Json.Linq;


Do we have enough unit tests / or did we manual test to ensure we are still good in net462/472/netstandard2.0? an nothing is broken?

net462/472/netstandard2.0 aren't targeted by any test project in this repo - that gap predates this PR. The good news is that STJ 6.0.10 itself targets netstandard2.0, so its behavior is consistent across all these TFMs. The net48 unit tests exercise all the same code paths (JsonHelper, cache serialization, IdToken parsing, etc.) and all pass. Happy to add a follow-up PR that adds net462/net472 to the unit test TargetFrameworks if you'd like explicit coverage.

Happy to add a follow-up PR that adds net462/net472 to the unit test TargetFrameworks if you'd like explicit coverage.

I don't think we should do this, but we need a test pass on key features.

Ran the unit tests locally targeting net462 (1,248 passed) and net472 (1,845 passed) by temporarily adding those TFMs — all passing, no JSON-related failures.

I don't think this is what @bgavrilMS suggested to do for the validation.

gladjohn · 2026-04-28T22:08:29Z

        {
-            // Output buffer to store the merged JSON
-            var outputBuffer = new ArrayBufferWriter<byte>();
+            using var outputStream = new System.IO.MemoryStream();


any concerns with swiching from ArrayBufferWriter to MemoryStream?

No concerns. MemoryStream.ToArray() has a small extra allocation vs ArrayBufferWriter, but Merge() isn't on any hot path. ArrayBufferWriter was only available from .NET 5+, so switching to MemoryStream was required to support net462/472/netstandard2.0.

ArrayBufferWriter actually ships in the System.Memory package and is available down to netstandard2.0 / net462 / net472 (MSAL already pulls System.Memory in transitively)? so it's not a TFM constraint as I can see.

nit - prefer using var outputStream = new MemoryStream(); without the fully-qualified System.IO. since System.IO should already be in usings of that file.

Tried it — ArrayBufferWriter is actually internal in the resolved System.Buffers 4.5.1 package for netstandard2.0/net462/net472, so it doesn't compile on those TFMs. The type only became public in later runtime versions. MemoryStream is the correct choice here for cross-TFM compatibility

gladjohn · 2026-04-28T22:13:16Z

Good PR overall - but we have no test coverage for the net462/472/netstandard2.0 builds of MSAL, so the swap from Newtonsoft to STJ on those TFMs (especially IdToken.Parse claim shapes and cache serialization) needs to be tested.

Adds net462 and net472 as TargetFrameworks to verify System.Text.Json works correctly on older .NET Framework versions after the Newtonsoft migration. Files excluded per TFM due to API availability: - net462: CertificateRequest/ECCurve not available (added 4.7.1/4.7.2); ImdsV2 unsupported (#if NET462 guard in production code) - net472: WebView2 test (Desktop lib targets net462 only); GetCertHash(HashAlgorithmName) not available (added net48) Results: net462 1248 passed, net472 1845 passed, 0 failures. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Copilot wasn't able to review this pull request because it exceeds the maximum number of files (300). Try reducing the number of changed files and requesting a review from Copilot again.

This reverts commit ed9afdf.

ashok672

Looks good. I tried building locally for all supported TFMs and the build is clean without warning. Thanks for this PR.

Robbie-Microsoft · 2026-04-30T20:17:02Z

Managed to validate the netstandard2.0 code path with actual test execution.

Approach: Created a standalone net6.0 test project (outside the msal-dotnet repo) that references MSAL via ProjectReference. When the consumer targets net6.0, MSBuild selects MSAL's netstandard2.0 binary — exactly the TFM under question. Used MSTest 3.6.3 which ships a native net6.0 adapter.

Tests written and results:

Test	Result
TokenResponse_StjDeserialization_ParsesAllFields	✅ Passed
TokenCache_SecondCall_ServedFromCache_NoExtraHttp	✅ Passed
ErrorResponse_StjDeserialization_ThrowsMsalServiceException	✅ Passed

Test Run Successful. Total tests: 3 Passed: 3 Total time: 1.1485 Seconds

Tests exercise:

Instance discovery JSON parsing (/common/discovery/instance)
OIDC metadata JSON parsing (/.well-known/openid-configuration)
OAuth2 token response JSON parsing (including �xt_expires_in,
ot_before, client_info, scope extra fields handled via JsonExtensionData)
OAuth2 error response JSON parsing (�rror, �rror_description, �rror_codes)
Token cache round-trip (write + read confirms internal cache serialization works)

All three STJ deserialization paths work correctly on netstandard2.0. ✅

Robbie-Microsoft and others added 2 commits April 28, 2026 16:24

Copilot AI review requested due to automatic review settings April 28, 2026 20:47

Robbie-Microsoft requested a review from a team as a code owner April 28, 2026 20:47

Copilot AI reviewed Apr 28, 2026

View reviewed changes

Robbie-Microsoft and others added 2 commits April 28, 2026 17:02

Copilot AI review requested due to automatic review settings April 28, 2026 21:17

Copilot AI reviewed Apr 28, 2026

View reviewed changes

gladjohn reviewed Apr 28, 2026

View reviewed changes

Robbie-Microsoft requested review from a team and ashok672 April 28, 2026 22:11

Copilot AI review requested due to automatic review settings April 29, 2026 18:52

Copilot AI reviewed Apr 29, 2026

View reviewed changes

Revert "test: add net462 and net472 targets to unit test project"

5df662b

This reverts commit ed9afdf.

ashok672 approved these changes Apr 30, 2026

View reviewed changes

gladjohn approved these changes May 1, 2026

View reviewed changes

Conversation

Robbie-Microsoft commented Apr 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes

Deleted

Infrastructure

Main library (~44 files)

Platform files

Tests / Lab

Testing

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

bgavrilMS commented Apr 28, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

gladjohn commented Apr 28, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gladjohn commented Apr 28, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

ashok672 left a comment

Choose a reason for hiding this comment

Uh oh!

Robbie-Microsoft commented Apr 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Robbie-Microsoft commented Apr 28, 2026 •

edited

Loading

Robbie-Microsoft commented Apr 30, 2026 •

edited

Loading