MSAL

A production application was terminated primarily due to persistent MSAL issues affecting Single Sign-On, login flows, and token validation. The application was otherwise stable, but constant MSAL-related failures caused repeated client dissatisfaction and made it impossible to maintain service quality.

MSAL's interactive authentication and client secret flows create opportunities for credential leakage, particularly when credentials are retrieved and stored in application state. Even certificate-based authentication alternatives carry similar risks of credential exposure.

PowerShell modules like AZ and MS Graph each include their own versions of MSAL, causing assembly load context conflicts when users load multiple modules in the same session. This results in silent failures or misleading error messages as the runtime continues using whichever MSAL version was loaded first, rather than the expected version.

The Azure AD v2 endpoint only supports OpenID Connect and OAuth, excluding older protocols like SAML and WS-Federation. Additionally, only a small set of APIs are accessible (own API, Outlook, Microsoft Graph), requiring fallback to v1 endpoint for other APIs. No migration path exists for v1 applications.

Starting with MSAL 4.52+, developers must explicitly specify parent window handles using WithParentActivityOrWindow APIs for Windows broker (WAM) authentication. Omitting this causes poor UX where auth windows hide behind the application, and window inference is no longer feasible.

Windows Broker (WAM) implementation has significant limitations: B2C and ADFS authorities aren't supported, it only works on Windows 10+ and Server 2019+, and older platforms must fall back to browser-based authentication. Developers must handle these constraints in multi-platform applications.

Developers must manually implement retry policies and claims challenge handling for Conditional Access scenarios in MSAL. Silent token acquisition can fail with claims challenges that require interactive re-acquisition, and HTTP errors (429, 500-600) need custom retry logic.

MSAL focuses primarily on authentication and token issuance but does not fully address access control issues or implement role-based and feature-level access control within applications. Developers must build custom authorization logic.

MSAL is not well-suited for complex microservices environments with decentralized identity requirements. Its centralized authentication approach doesn't map well to distributed systems where each service manages its own identity.

MSAL exception messages are not localized, making them unsuitable for displaying to end-users. While intended for developer troubleshooting, this creates friction when applications need to provide localized error information to international users.