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

[HockeyJustin]

Please follow the issue template below. Failure to do so will result in a delay in answering your question.

Library

• [x] @azure/[email protected]

Description

I have created an application using @azure/[email protected] (1.0.0-beta.5).

This has been fine for local development, but in iOS (everywhere), private browsing and other machines, there is an issue of 3rd party cookies being blocked. This prevents the whole application from working (it's pretty much all authenticated).

What can I do to get msal-angular to work on all browsers, without users having to turn off browser-wide settings/ defaults please?

Do I need to remove msal-angular and go with another library?

If so, is the recommendation to use msal-browser which supports the Auth Code with PKCE, or follow this tutorial released earlier this month?

I'm hoping msal-angular has a solution, but I can't see any updates planned on the roadmap.

[jo-arroyo]

@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.

[HockeyJustin]

@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.

[Lexcess]

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.

[majso]

It would be great to have some rough estimate.

A lot of users are using Safari.

[Lexcess]

As of three days ago Chrome has started introducing this behavior for 100% of users on Chrome 80+, so this is becoming a way more important issue for us.

Aug 11, 2020: The target rollout population has been increased to 100% of users on Chrome Stable versions 80 and above, and the actual proportion of users with the new behavior enabled is now ramping up to 100% gradually. Users will receive the new behavior when they restart Chrome. - Link

@jo-arroyo should we accept that for applications like ours we will have to drop MSAL-Angular?

[jo-arroyo]

@Lexcess Yes, unfortunately, you will need to use MSAL.js 2.0 directly for the time being. We are currently working to get the msal-angular upgrade on the roadmap.

[ollief87]

This seems like a pretty high priority issue. We now have production applications broken because of thise new behavior.

[ollief87]

@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

[jo-arroyo]

@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.

[Lexcess]

@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]

@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.

[Lexcess]

@jo-arroyo Thanks for the response and the sample. I'll let our teams know and see how they get along with replacing MSAL-Angular with MSAL.js 2.0

[Lexcess]

@jo-arroyo We have successfully used the sample in a test scenario. We see that it currently uses a popup and we also note that that is called out by the readme. Are there alternative mechanisms we can use with a SPA? Since by default all popups are blocked by policy at our organisation.

Edit: Also the sample seems to have issues on mobile devices. I'll raise an issue on the repo if we don't see a mistake on our end.

[tummah]

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.

[Lexcess]

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.

[dsm0880]

For what it's worth, it worked great for me and my team. We've been using ADAL for years and the switchover was great and pretty seamless. Again, everyone has their unique situations and challenges, but thought it was worth mentioning. We are on Angular 10.

[Lexcess]

@dsm0880 this thread around the MSAL-Angular package not the old ADAL-Angular one. I don't think ADAL has been updated in about three years.

[dsm0880]

@Lexcess Yup yup, if you read above I said "the transition." So we did switch over to MSAL, the one point of clarification that I should have mentioned above was we moved to MSAL 2.0 which includes PKCE addressing the 3rd party cookie issue. Hope that adds some clarity.

[Lexcess]

Sure, the pain of the transition in this thread was around moving from a dedicated Angular integration to a generic one. I could see how moving from an outdated generic ADAL to generic MSAL would be a better experience.

[ollief87]

We feel pretty let down by all of this. Solution is leveraging Azure AD B2B and Premium P2 licences. We are investigating other solutions now from Okta and Auth0...

[jasonnutter]

@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!

[Lexcess]

@jasonnutter thanks for the reply, the MSAL 2.0 code seems to still be working ok. We have noticed one or two glitches that could be state related (but have proven difficult to reproduce), so any more information on that or fixes related to that would be welcome.

In terms of MSAL-Angular 2 feedback; I would hope issues like SameSite won't crop up too often, 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. I can understand there being a lag between the two, but we really felt like were left to dangle with an active issue affecting our userbase. We really don't want to duplicate the work that MSAL-Angular covers, but it now feels like a risk to go back even when a v2 appears.

[jasonnutter]

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.

[github-actions[bot]]

This issue has not seen activity in 14 days. It will be closed in 7 days if it remains stale.

[HockeyJustin]

Just commenting to keep this open as the issue is still ongoing.

[ollief87]

Has anyone tried using Azure AD PKCE with a generic OAuth2 library such as https://www.npmjs.com/package/angular-oauth2-oidc?

[tummah]

I was able to use https://github.com/IdentityModel/oidc-client-js with angular and azure ad b2c with pkce.

[renjithgr]

@HockeyJustin Thank you so much for keeping this issue alive, we are facing the same challenges.

Can someone please confirm if the following error message is related to the issue being discussed in this thread?

JS/TypeScript Error: AADB2C90077: User does not have an existing session and request prompt parameter has a value of 'None'. Correlation ID: 9f240c63-ab1d-429e-83d9-8f42b90969cc Timestamp: 2020-10-06 12:33:50Z

[jasonnutter]

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

[renjithgr]

@jasonnutter Thank you for including this issue in the backlog. Appreciate it!

[MigukNamja]

Thank you so much @jasonnutter !!!

[StewSchrieff]

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.

[jasonnutter]

@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!

[silver-stack]

I have also been watching this issue as we have several applications that are affected by this and now it is becoming more of a problem.

We are using Azure B2C and have managed to modify our smaller apps to use the angular V2 sample mentioned earlier, However we had to make some modifications to the msal.interceptor.ts to pass the idToken instead of the accessToken.
Specifically here:

switchMap((result: AuthenticationResult) => {
                    //const headers = req.headers.set('Authorization', `Bearer ${result.accessToken}`)
                    const headers = req.headers.set('Authorization', `Bearer ${result.idToken}`);

                    const requestClone = req.clone({headers});
                    return next.handle(requestClone);
                })

We do have some other minor issues with this. The main one being that we sometimes get a blank screen on popup after successful authentication (about:blank). Users can close this, click the login link again an usually they get in successfully, however sometimes they get another blank screen and it can take a couple of attempts to log in.

Obviously this is not ideal, but is a work around. The fact that a preview will be coming later this month is much much welcome news. Thank you.

[jasonnutter]

Thank you everyone for your patience. The first alpha of MSAL Angular is now available: https://github.com/AzureAD/microsoft-authentication-library-for-js/releases/tag/msal-angular-v2.0.0-alpha.0

Please read the documentation carefully, especially if you haven't already upgraded your application to MSAL Browser v2.

I'm going to close this issue. If you have feedback or bugs on MSAL Angular v2, please open a new issue, thanks!