Connect to Azure AD-secured APIs in SharePoint Framework solutions should be updated to use MSAL instead of ADAL

[litex1982]

[Enter feedback here] as Microsoft is retiring ADAL and supports would end by Dec 2022, what is the alternative way from SPFX side to connect to AAD secured API? Is there any chance to document a new approach, ie. MSAL, including the necessary setup etc from Azure AD application configuration side.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 47b09a1d-5520-82e2-64f5-7aaae817720a
• Version Independent ID: 0e3dcdc4-3a49-b4c7-f525-1c618cf5e21e
• Content: Connect to Azure AD-secured APIs in SharePoint Framework solutions
• Content Source: docs/spfx/use-aadhttpclient.md
• Product: sharepoint
• Technology: sharepoint-framework
• GitHub Login: @VesaJuvonen
• Microsoft Alias: vesaj

[ghost]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[kbeeveer46]

I am interested in this, as well. Is ADAL the reason why SharePoint sites barely work in Safari because of its cross-site/third party cookie blocking Safari enables by default? I know Microsoft put a hack in place to refresh the page to get around it but that doesn't work most of the time on my site. I have a site that calls about 10 APIs on page load and the site literally reloads 10 times and the API calls still fail. I can understand putting that hack in place temporarily while a a fix is being applied but I have yet to see any communication from MS that they plan on implementing a permanent fix.

Firefox just did what Safari does but I believe they put exceptions in place for certain authentication cookies so it doesn't have the issues Safari does. As far as I know, Chrome has plans to block cross-site/third party cookies in the near future. When does Microsoft plan on implementing a permanent fix for this issue?

[lucabandMSFT]

hey folks, thanks for the feedback. We have been used MSAL V1 in our client factory libraries for quite a long time now. The documentation is not updated and we are working to fix it.

The reason why Safari has problems is different: yes, we are using MSAL but we are using V1 which still relies on implicit flow that requires an hidden iFrame to acquire the token. and because of ITP, such silent SSO fails.

We do have a capability in the library to avoid the auto-redirect and ask for pop up instead. AADTokenProvider has a cancel() function you can call to avoid auto-redirecting if a redirecting event is generated.

Then redirectURL property of the AADTokenProvider class wil give you the Url to redirect to for getting the token. In this way the entire flow can be controlled by the web part developer instead of being managed by SharePoint automatiically.

Hope this helps.

[ghost]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues