ADAL.js/AAD SPFx warning

[wictorwilen]

Category

• [ ] Question
• [ ] Bug
• [X] Enhancement

  Expected or Desired Behavior

I recommend that you, for the moment being, have a visible warning on all SPFx samples that uses Azure AD Apps with ADAL.js. SPFx main target users are enterprise users and many of them are (still) using IE and a vast majority of them are having their tenant name in the trusted/intranet sites zone. ADAL.js does not work with this configuration. I would say in most cases this goes unnoticed for developers as they are mainly using other browsers than IE and most of the time they are using developer tenants or localhost not in your trusted/intranet zone so it goes unnoticed there as well.

Hopefully we get better ways in the future to get around this...

[VesaJuvonen]

thx Wictor. We have following article in the queue to be released also in the dev.office.com/sharepoint, which clearly pinpoints the current limitations. We are working on new tech for this and things will get much much better. We are in the review stage with this article, so if you have any additional input for this, it's more than welcome.

• https://github.com/SharePoint/sp-dev-docs/blob/staging/docs/spfx/web-parts/developer-guide/connect-client-side-web-parts-to-aad-secured-resources.md

[wictorwilen]

Yes, I've seen that (and also seen what's been cooking in the SPFx to make it easier). To be clear and Vittorio confirmed it for me, ADAL.js will never work with IE + multiple zones - so guidance on securing resources with ADAL.js is not going to work for any larger enterprise that use Windows as a desktop platform. And that guidance in the first sentence says that this is the way you should do it (ADAL.js) which will not work in enterprise scenarios, unless you're a developer working on Mac (nudge @waldekmastykarz :-)). The warning about IE zones should be the firs thing in that guidance: "If you're developing for a target user that might use Internet Explorer in a scenario where the SharePoint Online Url is in the intranet zone or trusted zone, which is required for SSO and Open With Explorer to work seamless - you should not use ADAL.js".

[waldekmastykarz]

If you're developing for a target user that might use Internet Explorer in a scenario where the SharePoint Online Url is in the intranet zone or trusted zone, which is required for SSO and Open With Explorer to work seamless - you should not use ADAL.js

Shouldn't they be using ADAL.js specifically or OAuth implicit flow in general (basically no way to get access token securely other than using what you've spotted in the framework, which will likely have limitations of its own)?

[wictorwilen]

It's ADAL.js that does not support this, since it uses the iframe approach and mixed zones. OAuth implicit flow works if the endpoints were located in the same zone as their trusted site. I've heard rumors about this getting fixed in MSAL but there's still no MSAL.js equivalent. Set up at Windows machine, domain join it, use ADFS to get SSO to your 365 tenant and you'll experience exactly this scenario that will not work for the end-users.

[waldekmastykarz]

The only alternative that I can think of would be to redirect the whole page to get the access token and then catch it in the page on the callback, but it would be a very poor experience if each web part on the page did it for itself. So in other words, the approach described in the guidance is viable as long as users are not using IE with specific configuration of zones, correct?

[wictorwilen]

You could do that, but as you say the experience will be poor and defeat the new modern UX. Also you need to build your own redirect infrastructure where you pass the accesstoken in the URL, since you can't share cookies.

[wictorwilen]

Or you have the option to create a SharePoint add-in and hijack that appredirect to get the ACS access token :-)

[waldekmastykarz]

You could do that, but as you say the experience will be poor and defeat the new modern UX. Also you need to build your own redirect infrastructure where you pass the accesstoken in the URL, since you can't share cookies.

That's done already by default in OAuth implicit flow: you navigate to the token endpoint which send a 302 redirect to your application with the access token in the URL hash. ADAL.JS already does processing of it, so the only thing that you would need to do is to request the token by navigating to the token endpoint in the whole page rather than inside an iframe which you cannot access x-zones.

[wictorwilen]

I recall I did try that a year ago or something and what I recall is that I ended up in a infinite redirect loop or something like that.

[waldekmastykarz]

Still, even if it was working, it would be a poor experience from the end-user point of view.

[wictorwilen]

So, we need a little somethin' in the framework to make this happen ;-)

[VesaJuvonen]

and we are working on that - but not quite yet... it looks good though.

[jtlivio]

Great news :)

[BigEaseGueldi]

Are there any updates on this? We currently have some nice scenarios using the MS Graph - but there's still the IE problem. Thanks!

[artokai]

The recently published PowerBI (preview) webpart seems to be able to get the required auth tokens from an undocumented SharePoint REST API endpoint /_api/SP.OAuth.Token/Acquire. Hopefully this will soon be exposed via the SPFX framework since the possibility to make authenticated rest calls to external endpoints is really a must have feature for all kinds of integration scenarios.