sp-dev-docs
sp-dev-docs copied to clipboard
SharePoint
Plans for MSAL 2.0 / Third party cookies
Category
- [x] Question
- [ ] Typo
- [ ] Additional article idea
Question
Hey there, I'm just wondering if there's any plan to support MSAL 2.0 and the new PKCE flow when using the aadtokenProviderFactory. It seems like a good avenue for getting around the well known third-party cookie limitation with implicit flow, which numerous people have run into (if not in name, then in spirit): #5376, #4476, #2685, etc.
As a bit of background, I've been using SPFX for the past three years (it's wonderful!) and have been fighting against the third-party cookie limitations every since the aadtokenProviderFactory was released. I mainly use it for accessing a multi-tenant API my company runs and which we sell to various companies. But I've also used it for accessing MS APIs in one-off projects.
In the past year, the amount of AADSTS50058 errors I've run into seems to be increasing. Just the other day, I deployed a new web part to a fresh tenancy and I needed to adjust all users' chrome settings to allow the cookie to generate. This used to just be an issue with IE and Safari, which I could educate around, but with Google's recent push towards stricter cookie policies (such as in Chrome 83) and with Firefox putting an increased focus on security, I'm starting to worry that in a year all of my clients will need to start explicitly enabling certain policies. This isn't sustainable, as some of these clients reach upwards of 10,000 users.
So, PKCE might be the solution I'm looking for. To restate my question, then, I'm wondering if there's any plans to support PKCE through MSAL 2.0, or if there's another solution in the works to get around third-party cookie limitations.
Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.
That is a good question. I would also like to hear an answer. thanks
This month's SPFx community call mentions moving to MSAL, although I didn't see anything about PKCE. Is this accurate?
This month's SPFx community call mentions moving to MSAL, although I didn't see anything about PKCE. Is this accurate?
I've seen this too but in a different video: (https://youtu.be/-dVZM-UROb0?t=1139) and the way I understood it is they're moving to MSAL v1 (which is still depending on the implicit grant flow). They mentioned this would come together with some other 'functionalities and work-arounds' to support auth in browsers where ITP (Intelligent Tracking Protection) is turned on. They also appear to be working on implementing MSAL v2 but no timelines were mentioned for either...
Anecdotally, I noticed msal v1.4.0 being used to generate tokens this week.
Hi guys, I'm also curious to know. I understand that it is a complicated issue. I incidentally wrote an article about this last year. It seems there hasn't been a significant change since then. (The current version of MSAL in use is 1.4.16 in SPFx 1.15.2 as I can see.)
Are there any plans already for the near future? Please let us know, we're very interested!
Any evolution on this topic? Anyone able to bypass this issue somehow?
MSFT mentioned in #7759 (March 2022) that they were working on updating to MSAL V2...Which I assume they are targeting before Google deprecates 3rd party tracking at some vague point in the future :). But this impacts us as well so would love to get some kind of updated timeline!
We are impacted heavily by this as many users now have to re-authenticate with redirects every hour. We can solve it with a custom solution but we would really like to stick with a standardized solution provided by Microsoft.
Last year we switched from a custom authentication solution to MSAL under the expectation that Microsoft will 'take care of us' so I hope we will not be disappointed.
@lucabandMSFT any news on a timeline for this? I assume you will complete the upgrade to MSAL2 before third party cookies are blocked by default in Chrome and/or Edge - however, this is impacting us immediately for those using Safari on Mac as third party cookies are blocked by default.
so.. PKCE will not help you here. PKCE is a way to get the code in authorization code flow (MSAL V2 and above) in a more secured way.
However, when 3rd party cookie are disabled, the iframe used by silent SO from MSAL will need to do a full page refresh and get the token on the main frame because the iFrame will not get the "logi.microsoftonline.com" cookie that the main frame already has. While implicit flow is a mess as this will happen every time a new token is needed, in authorization code flow this (the full page redirect) will still happen once when 3rd party cookies are disabled because the act of getting the code in MSAL.JS happens in an iframe.
We are currently working with AAD folks to ensure that doesn't happen. I cannot share details here (yet) on the work that we are doing and the timeline but rest ensured that:
- yes: we are doing work to adopt MSAL V2+ and as a consequence authorization code flow
- as part of that, we are also working with the Azure AD team to ensure we can get rid of the initial full page refresh when 3rd party cookies are disabled.
@lucabandMSFT I really appreciate your response. Thank you very much for that.
I take the liberty of asking if there is any progress on this? Maybe we can get a bit closer to timeline of some sort? We have a terrifying amount of users affected by this. However, it has helped a lot that I can say with confidence that Microsoft is aware of the issue and working on it. That has bought us some time.
@lucabandMSFT any news on a timeline for this? I assume you will complete the upgrade to MSAL2 before third party cookies are blocked by default in Chrome and/or Edge - however, this is impacting us immediately for those using Safari on Mac as third party cookies are blocked by default.
Same for Firefox with standard parameters.
As a workaround, we instructed our customers to add https://teams.microsoft.com in the tracking protection exceptions (from about:preferences#privacy page).
This prevents our compose extension to ask for creds again (which is blocked because of the iframe).
Folks, sorry for my delay in answering. We are working on it. The current plan is to transparently enable MSAL + Authorization Code Flow starting January 2024.
That's the current plan and I will keep you updated if something changes. If everything goes by plan, I will send an update on this issue here once the new code is available to all customers.
@lucabandMSFT are we still looking good for this month for the new auth flow rollout?
Also @lucabandMSFT: what is the plan exactly from a tech perspective? Will the page redirect through login.microsoftonline.com if there are entra secured webparts on it? And what if there are multiple webparts from multiple entra apps?
Happy 2024 folks, couple of comments:
- @AtDH01 - yes, plan still look good for the authorization code flow to roll out. if it's not January will be the first week of February but we are not predicting anything later than that.
- @martinlingstuyl - once the code is fully deployed (plan is to fully deploy it by end of January / early beginning of February) we will retrieve the refresh_code at page load, no matter if there's code that needs an access token or not. Then we will use the refresh_token to get all the required access tokens if / when needed.
Great, thanks for the info @lucabandMSFT. How will this be rolled out? New SPFx package version?
- Then we will use the refresh_token to get all the required access tokens if / when needed.
So we're talking about a multi-resource refresh token?
New SPFx package version?
I believe the idea was that this ought to work out of the box for all SPFx versions. Right @lucabandMSFT ?
@martinlingstuyl is correct: no new package needed; we are making the change on our side. As long as the solution uses our SPFx libraries it will start use the new flow with no changes needed.
@martinlingstuyl , the flow I'm talking about is this one: https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-auth-code-flow. The refresh_token is used for acquiring all tokens the app got pre-approval for.
@lucabandMSFT Do we now if this is fully rolled out? We are still facing redirect issues.
@agtenr, @Vighough: apologies for my delay in answering .
feature is rolling out.. unfortunately at a slower pace as expected / desired. if you have a specific tenant you want the feature to be enabled please send it here (or shot me an email at [email protected] if you feel uncomfortable to share tenant information here) and we will be able to enable the feature on your tenant right away.
Thanks again!
Is there any chance that this unlocks the ability to host spfx webparts also in outlook add-ins (in message extension I mean)?
One of my customers received some complaints from Firefox users where the page kept refreshing. I have been investigating, and it was related to a missing MS Graph permission scope, which was removed/unapproved.
The "clean" solution would be to add the missing permission scope, but I believe the problem is more significant than just adding that permission.
First, there was no easy way to discover that it was an issue related to the permission scope. Here you can see an example:
https://github.com/SharePoint/sp-dev-docs/assets/2900833/232c8c23-4e51-4505-80bc-7b76ddd87ca9
I had to record the network traffic to notice what was happening. With the fix for third-party cookies in place on tenants, the users get redirected to the /_forms/spfxsinglesignon.aspx page and return to the original page.
The main problem is in the redirect logic; as it is a full page reload, the component that required the token will redirect the user repeatedly. However, on the /_forms/spfxsinglesignon.aspx, you receive an error that there is a missing consent for a permission scope.
I suggest implementing a way to capture this error. For instance, when the /_forms/spfxsinglesignon.aspx gets a missing consent, something is written to the cache. When the code requests the token again, the MSAL library should validate if it has already performed the redirect, and if that is the case, return an error. That way, it would be similar to the implicit grant flow where you would retrieve an error, and we could tell the user some configuration is missing.
One of my customers received some complaints from Firefox users where the page kept refreshing. I have been investigating, and it was related to a missing MS Graph permission scope, which was removed/unapproved.
not only Firefox, Edge and Chrome with same behavior for some weeks now.
@estruyf @aaclage. is this still happening? if yes, mind sharing a tenant where we can see the repro?
Thanks!
@lucabandMSFT The sample below is happening in my prod Tenant but could not reproduce in a sandbox:
Edge Behavior (Version 122.0.2365.59): First time access same behavior as shown in image below, appear empty and refresh page accepting the Graph permission, close browser and open and works without refreshing. Next day or new session have the same behavior.
Chrome (Version 122.0.6261.95 ) When access appear empty and refresh page accepting the Graph permission
Have custom webpart that call graphs (using API permissions), first time access:
PS: the refresh is automatic not manual.