Authentication unpacked: What does MSAL actually do? Ben Reader

The presentation begins with a brief overview of MSAL, outlining its role in simplifying the authentication process across various platforms. Despite the widespread understanding of MSAL among the audience in 2025, Ben feels compelled to reiterate its foundational aspects before delving into more technical discussions, particularly concerning assembly load context (ALC) issues that arise during its implementation in PowerShell modules like AZ and MS Graph. These modules have incorporated their own versions of MSAL, leading to potential conflicts when users attempt to work with multiple modules in the same session. Ben articulates the frustrations and complications associated with overlapping library versions, outlining scenarios where users encounter silent failures or misleading error messages. He stresses the urgency of addressing these issues through a unified library approach to minimize compatibility problems. This leads to a critical juncture in the lecture where the discussion shifts towards alternatives to MSAL. ... A key takeaway from the session is the notion that while it is technically feasible to write your own authentication logic, it is rarely recommended outside of specific contexts. Ben shares practical examples where developers may feel compelled to create their own solutions. He highlights several authentication flows, including interactive authentication, device code flow, client secret flow, and managed identity scenarios, showcasing both the simplicity and potential pitfalls of custom implementations. ... Uh and then we're going {ts:142} to talk about ALC or assembly load context and essentially why I believe and this is just a personal opinion uh {ts:148} that there are some issues with how we've implemented authentication uh in PowerShell and in the modules that we