Support for MSAL.js 2.0?

[ghost]

Hi there,

Any plans to support MSAL.js 2.0?

Thanks!

[philtweir]

I'll need to take a look at this myself for our own work - keen to submit a PR if it would help, but if there are any thoughts or on-going efforts, also keen to avoid duplication.

Will get started, but - @mvertopoulos - are there any particular requirements or structuring I might miss? (or WIP?)

[ghost]

I'm not aware of any WIP ...

[philtweir]

Good progress here: https://github.com/flaxandteal/vue-msal/tree/feature/msal2 -- I am able to log in and out with MSAL 2.

As our team's target is B2C, we have had to wait a bit longer for support in MSAL.js 2.x.x, but it seems to be getting there. However, there is still a blocker: https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/1795 For the moment, that means that the only way of testing is to have a proxy token endpoint (e.g. a simple pass-through Azure Function), and override MSAL's token endpoint. There is a commit to do that, which needs to be removed as soon as that issue is resolved.

Feedback on the rest would be appreciated. Key points:

• Most public methods are now asynchronous. As well as consistency with MSAL 2's API, this allows transparent waiting for a new MSAL::initialize method - the constructor now contains only the first few synchronous calls, with the remainder moved to finish a little later due to async setup. However, signIn, signOut and isAuthenticated will wait for MSAL::initialize if needs be, so consumers can call as normal (albeit with an await).
• The configuration cache is now private within MSAL, so to minimize immediate changes, I am creating a fresh MSAL 1.x AuthCache that vue-msal can use as normal. It would be good to migrate away from this, and lose the MSAL 1.x dependency, but perhaps not a blocker to getting MSAL 2 support.
• Mostly due to the async changes, the API for vue-msal is not directly compatible with MSAL 1.x - this isn't impossible though, so conceivably support for both could be retained in one interface, or via configuration. Again, I think ability to use MSAL 2.x is probably a higher priority, as that could get a bit fiddly.

If the general approach looks acceptable, I can open a PR - still a fair bit of tidy up and testing to do, but as long as there's something to iterate, that seems sensible - will wait for some feedback though.

---

Broader context for anyone who hasn't been hit by this: since ITP 2.3 came into Safari (March), the Implicit Code Flow has been blocked. This means apps built on MSAL.js 1.x (e.g. current vue-msal apps) will not work on e.g. recent iPhones without users actively disabling security in their browser settings. MS are only targetting the fix at MSAL.js 2.x

[philtweir]

@mvertopoulos any thoughts on the above please? If it's broadly OK, I can get a PR together and tidied, hopefully in time for MSAL.js on B2C being solved -- MS are already doing a hard push on MSAL 2 while it's pre-release (and it looks like more browsers will be making MSAL 1 difficult), so it would be good to get ahead of that.

[tylermurry]

@philtweir / @mvertopoulos - The MS issue you linked to has been closed and I can personally confirm it has been solved in my own use-case (MSAL 2.0 library against a B2C tenant using PKCE is working great).

Has there been any progress on supporting @azure/msal-browser?

[philtweir]

I've not spent time on a pull request as there hasn't been any indication whether that'd be reviewed from @mvertopoulos - I see there's also https://github.com/yoerankaniok/vue-msal so not too sure what the best approach is, but there's not much option beyond consolidating around a fork if this repo isn't going to have MSAL2 support.