what is the proper way to authenticate SPFX Web-parts?

Core Library

MSAL.js v2 (@azure/msal-browser)

Core Library Version

2.14.2

Wrapper Library

Not Applicable

Wrapper Library Version

N/A

Public or Confidential Client?

Public

Description

We currently use MSAL 2.14.2 to get our AAD token to be able to get an access token from our own API. The problem is that ITP on Safari breaks the authentication flow and the only solution there seems to be is to rely on pop ups and redirects.

This Microsoft article states that AadHttpClient with the implicit flow should be used instead to bypass 3rd party blocker issues, but it seems like it too uses a hidden iFrame and ends up relying on redirects (We have implemented it and we get a redirect after the SP page has loaded, then it works).

What is the best way to get a token from SPFX web-parts then without impacting the user experience? Having in mind that all browsers seem to be adding this type of feature, will pop ups and redirects become the standard if there is no other solution?

Thanks.

UPDATE: We were able to run this Microsoft tutorial locally that implements AadHttpClient on SPFX and it does the login redirect after SP login.

MSAL Configuration

No response

Relevant Code Snippets

No response

Identity Provider

Azure AD

Source

External (Customer)

[hectormmg]

@levisalarcon it does currently use an older version of MSAL I believe (I think the docs are outdated, it actually uses MSAL v1 and will probably migrate to MSAL v2 soon).

Regarding this part of your quesiton:

Having in mind that all browsers seem to be adding this type of feature, will pop ups and redirects become the standard if there is no other solution?

Yes, interaction is always necessary if MSAL cannot renew the tokens silently, this is because of 3p cookies being blocked by browsers. I believe the AadHttpClient already takes care of falling back to interaction. There’s no way to guarantee tokens will always be fetched silently.

[levisalarcon]

thanks for the answer @hectormmg.