Description
One of the most common complaints is the ability for people to pass in additional arguments to the underlying MSAL library that we don't expose ourselves. Instead of us having to add support for every single parameter, we might want to give people the "keys to the kingdom" and offer a lower level experience where they get to customize everything.
We would keep our library around, but we would "scaffold" the msal code into the templates (like we did for Azure AD/B2C) in previous versions and that would enable people to customize, update and interface with msal however they deemed fit. It doesn't pose a big burden on our side, as we would still need to update the library periodically, and we don't really care if that change is on the templates or on a nuget package. The main difference here would be that customers would be responsible for keeping the JS version of the library up to date (same as with a SPA) but will gain the ability to add features as needed without waiting for us to support them.
- Blazor Azure ADB2C Authentication popup size does not match content #37365
- Support passing more options to WASM AAD auth #32782
- Add support for "prompt="select_user" with WASM / MSAL #32640
- Blazor Webassembly AAD and AAD B2C support improvements #27549
- .Net 5 RC2 - Blazor Wasm - AAD B2C SignUpSignIn catch error 'AADB2C90118' to start Password Reset userflow #27119
- Provide a way to set loginHint in Blazor with AAD auth #19925
- In Blazor WebAssembly, allow dynamic query string parameters when redirecting to IDP #33784