microsoft-authentication-library-for-js: Preventing 3rd Party Cookies block when using MSAL Angular (1.x)

@jo-arroyo . Thanks for getting back to me.

This is a big issue for us. Looking at the MSAL.js 2.0 sample, I would almost need to make my own version of msal-angular to get this to work within the angular ecosystem (e.g. Route Guards, Refresh Tokens etc).

I’m not keen on doing all that work, only to then scrap it and use the official msal-angular 2.x.

Do you have any idea of when this might be updated please? Even an idea of months/quarter/6m/next year would help determine whether I can wait for the update or have to do the work myself.

@StewSchrieff The roadmap will be updated shortly (#2388). For MSAL Angular v2, we are planning to have a preview version available soon (later this month). I’ll post here when that is available. Appreciate the patience!

@ollief87 We are planning to have a sample demonstrating using MSAL.js 2.0 with Angular soon, and we will soon have an update on the roadmap.

@renjithgr Most likely, yes. You should be able to resolve by invoking interaction.

Checking in here, as it’s now past early October (mentioned by @jo-arroyo ) - I don’t see this scheduled on the roadmap at this point, and am curious if there is an updated timeline as to when we can expect to see msal-angular updated to msal-browser 2.0?

As many have said, this is an important update as a growing number of users are unable to authenticate in their browser of choice.

I do see this issue on the backlog (thanks @jasonnutter ), which sounds like there could be some movement, but I don’t see that reflected in the roadmap.

@Lexcess We now have an initial sample demonstrating how to use MSAL.js 2.0 with Angular Single Page Applications available here.

We will also use this as we start working on msal-angular v2. We have started planning and design for msal-angular v2, but we are not anticipating a preview version available until at least early next quarter (early October). Hope this helps with your planning. We will update our roadmap once we know more.

@jo-arroyo sorry to be a bit pushy on this, but we are getting increasing push back from users on this topic.

Can we have any definition for what soon means: days, weeks, months? We need to know whether to wait, or just start ripping out MSAL-Angular now ourselves. Also can we safely assume the sample will cover Angular Single Page Applications since that is the use case we are talking about here?

@jo-arroyo can you please provide an example of using MSAL.js 2.0 directly in Angular? We’re a very large MS Enterprise customer and feeling a bit let down by the lack of support or roadmap for this issue

but if you are going to keep MSAL-Angular as a going concern it feels like a bare minimum would be to announce when updates to the core libraries will flow out to the framework integrations.

That is fair feedback, and we are working to get better at communication about the roadmap, and decreasing the time it takes to update the wrapper libraries to support new versions of the core libraries.

It would be great to have some rough estimate.

A lot of users are using Safari.

@Lexcess Apologies about the frustration using MSAL and Angular. The sample in question is updated to show how it could work using redirects instead of popups. There are still a couple known issues (e.g. updating state properly), but we’ll be addressing those soon. MSAL.js v2 requires async processing of redirect responses, which has introduced new complexity into mechanisms like the guard that we had to work through.

Please note, we will be working MSAL Angular v2 in the coming months (the sample is the start of the work for that).

We appreciate your patience and are interested in any feedback you have, thanks!

As an update. We looked at the sample @jo-arroyo linked and it was a pretty bad experience. It used a popup model, and most browsers blocked the popup by default. So users had to approve the popups, it also outright failed on our tests using mobile devices. After some investigation and conversations with Microsoft Premium Support we managed to modify the integration to use the alternative redirect model.

So in summary for anyone else caught up in this; we got an Angular SPA working using MSAL v2 via the given sample code, modified to use the redirect model.

That said, this whole experience has been pretty painful for us and terrible for our end users. If I had heard about oidc-client-js two weeks ago I might well have gone in that direction instead.

This was so frustrating for me I decided to switch away from msal. I’m building an Angular app with Azure AD B2C and couldn’t fathom having to tell my users not to block third party cookies (how un-user friendly!). So I went with this library: https://github.com/IdentityModel/oidc-client-js. It was so easy to implement with Azure AD B2C (took about a day with troubleshooting) and supports PKCE. A real life saver!! I followed this blog to implement with implicit flow: https://www.taithienbo.com/how-to-authenticate-user-against-azure-adb2c-from-angular-app-using-oidc-client-js/ and then I followed the follow-up post to implement PKCE: https://levelup.gitconnected.com/obtain-access-token-via-authorization-code-grant-with-pkce-in-angular-using-oidc-client-js-and-d481873b5a8a. There were just a couple “tweaks” to support Azure AD B2C vs Microsoft Identity Platform (change the authority, basically) and I had to implement support the reset password flow. Hope this helps anyone who was banging their head against the wall with msal.

I just raised this very same question (I’ve now closed my issue as dupe).

Safari is now using this behaviour, inprivate/incognito users now are seeing this behaviour and finally Chrome has begun rolling out this behaviour to increasing subsets of users over the last two weeks.

We really don’t want to have to reintegrate our applications to the core library, because as HockeyJustin says, we’d have to reimplement the Angular integration. However the browser vendors are pushing this hard. So even a ballpark timeline would be really useful.

@HockeyJustin We’re aware of the issues with 3rd party cookies with msal-angular as it still depends on MSAL.js 1.0. We will upgrade msal-angular to work with MSAL.js 2.0. However, that work has not yet been scheduled. We will update our roadmap when we schedule that work. For now, you can use MSAL.js 2.0 directly if you need to use the auth code flow.