Microsoft Authentication suddenly failing in iOS mobile app after recent Microsoft Entra updates

[pme442]

Due to recent changes rolled out by Microsoft, https://techcommunity.microsoft.com/blog/microsoft-entra-blog/upcoming-conditional-access-change-improved-enforcement-for-policies-with-resour/4488925, some of our users are suddenly having trouble authenticating in our mobile app. It has not happened to all users yet because these changes are a gradual rollout. But, by the fall, it looks like this will be very wide-spread.

In the app, I am using the Microsoft.Maui.Authentication.WebAuthenticator.AuthenticateAsync() to open the Microsoft Login browser window. Then to get the token, I do a POST with grant_type=authorization_code. I have been doing it this way for years and never had a problem.
But since Microsoft has been pushing these security changes to Entra, the login process now fails when trying to get the token. Here is the response we are getting back:

{"error":"interaction_required","error_description":"AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'. Trace ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx Correlation ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx Timestamp: 2026-07-29 21:05:23Z","error_codes":[50076],"timestamp":"2026-07-29 21:05:23Z","trace_id":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","correlation_id":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","error_uri":"https: //login.microsoftonline.com/error?code=50076","suberror":"basic_action","claims":"{"access_token":{"capolids":{"essential":true,"values":["xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"]}}}"}

Not a whole lot of information on this, but I did find a few articles talking about how the app should handle this by gathering the claims in the response and sending them back as a claim_challenge in a second request to try and get a token. But they are all very vague and I am not having much luck in getting anything to work.
Has anyone else had to deal with this?
I am just looking for pointers or any helpful information.
Thanks.

[tltaylor1]

I think what broke you is the enforcement change you found, and the mechanism to handle it is the claims challenge flow. Some background so the fix makes sense.

Before this change, Conditional Access was largely evaluated at the interactive authorize step, and the session that came out of it carried you through subsequent token requests. Entra now re-evaluates policy when tokens are issued for a resource, so a code redemption or a refresh can come back with interaction_required and AADSTS50076 even though the sign-in itself succeeded moments earlier. Your flow feels this immediately because WebAuthenticator.AuthenticateAsync plus a hand-built authorization_code POST has no path for the service to tell you "this token needs more proof" other than failing the request.

The error response you are getting should contain a claims field alongside the error code (the same value also appears in a WWW-Authenticate header when a resource rejects a token). That value is the challenge. You cannot satisfy it at the token endpoint, which is why resubmitting things there goes nowhere. The flow is: take the claims JSON from the error response, URL-encode it, and append it as a claims parameter on a fresh interactive authorize request, then send the user back through the browser sheet. Entra reads the challenge, walks the user through the multifactor step the policy demands, and the new authorization code redeems normally. The relevant documentation is "Claims challenges, claims requests, and client capabilities" on Microsoft Learn; it is thin, as you found, but the parameter behavior is all there.

So with your current architecture: detect error == "interaction_required", extract claims if present, rebuild your authorize URL with the claims parameter, run WebAuthenticator again, and exchange the new code. That will unblock you.

Two caveats before you settle there. First, the iOS sheet under WebAuthenticator is ASWebAuthenticationSession, and depending on session cookie behavior your users may be walked through multifactor more often than you would like, because nothing durable proves the device between runs. Second, if your tenant's policy ever requires a compliant or managed device rather than just multifactor, no plain web view can satisfy that at all; that claim only comes through the platform broker.

Which is the real recommendation: this class of change is why Microsoft pushes the identity libraries. MSAL.NET (Microsoft.Identity.Client) handles exactly this pattern: AcquireTokenSilent throws MsalUiRequiredException, and you call AcquireTokenInteractive with .WithClaims(ex.Claims) and the library does everything described above. Adding .WithBroker routes through Microsoft Authenticator on iOS, which brings single sign-on, fewer multifactor prompts, and the device claims that a web view can never produce. The years your current flow worked were years when nothing challenged it; continuous access evaluation and this enforcement change make challenges routine, and the library is where that complexity is maintained.

If you have access to the tenant, the Entra sign-in logs will confirm all of this: find the failing request, open the Conditional Access tab, and you will see which policy demanded the multifactor step. Worth checking what the logs show, and happy to go deeper on the MSAL setup if you head that way.