Causes the whole app to slow down before login

[KyLeggiero]

Describe the bug:
When running an app with the Intune SDK linked, it is so slow before login that it takes multiple seconds for the system keyboard and app to recognize a keystroke. This makes it unusable by customers.

My investigation seems to indicate that this is associated with excessive logging, allocations, and a memory leak. This is borne out in the screenshots.

To Reproduce
Steps to reproduce the behavior:

1. Run an app using Intune, which is not logged-in

Expected behavior:
App is responsive

Screenshots and logs:

• Screenshots and videos: https://photos.app.goo.gl/fPFibgshQbLKbewc6
• Logs: https://drive.google.com/file/d/1dIgHKuc-BpJvUZ5LptOWTc0SUE_SZc56/view?usp=sharing

Smartphone (please complete the following information):

• Device: iPhone 11, iPad Mini 4, iPad Air (3rd Generation)
• OS: iOS 13.6.1, iPadOS 13.6, iPadOS 13.6.1

Intune App SDK for iOS (please complete the following information):

• What version of the Intune SDK are you using? 12.4.0 Are you using the latest version? No
• What platform is your app based in (Java, Xamarin based, Cordova, etc)? UIKit
• For errors post build, does the app launch without being Intune SDK integrated? Yes, without this problem
• Who is the customer? Why do you need to know?
• Do you see a trend with it only being reproduced on a specific device? No

Additional context:
This appears to be a critical flaw which causes both massive logs and unnecessary allocations. It appears to also involve memory leaks.

Intune took up so many memory allocations that just debugging it crushed my 2020 MacBook Pro 16" to a crawl, and filled up its hard drive with swap files.

[KyLeggiero]

I assume y'all didn't intentionally add merge conflicts to the bug report template. With that assumption in-mind, I've filed #105

[Kyle-Reis]

Hey @BenLeggiero, is your app linking against MSAL? This sounds a lot like this issue, which was fixed in 12.6.1. Could you try upgrading to the latest release and let me know if that addresses this for you?

[KyLeggiero]

That issue looks unrelated, @Kyle-Reis, but I'll try using the latest releases just in case.

[KyLeggiero]

This was never easy to reproduce - often one device would exhibit this bug consistently for days before suddenly working as expected. Other devices might never exhibit this behavior, some of these would suddenly start after awhile.

All that said, after updating Intune and MSAL, we cannot reproduce this on the devices which could reproduce it yesterday.

[KyLeggiero]

We're still investigating, but after updating the IntuneMAM and MSAL frameworks, we're getting this crash. We aren't 100% sure where it's coming from, but IntuneMAM/MSAL might be contributors. Downgrading them once again, and running the IntuneMAMConfigurator, had no effect. Reverting to our commit for our shipped product also had no effect; the crash persisted:

2020-09-04 15:14:23.807882-0600 Smartcrypt for Intune[4784:269760] -canOpenURL: failed for URL: "msauthv2://broker" - error: "The operation couldn’t be completed. (OSStatus error -10814.)"
2020-09-04 21:14:23.809Z Error Domain=com.apple.AuthenticationServices.WebAuthenticationSession Code=3 "The UIWindowScene for the returned window was not in the foreground active state." UserInfo={NSDebugDescription=The UIWindowScene for the returned window was not in the foreground active state., MSALCorrelationIDKey=A90F2036-2885-4D78-8743-E6BE4984F85B}

I've seen a similar crash when trying to use 1Password to fill in the same login field.

[Kyle-Reis]

Hi @BenLeggiero, this doesn't look like a crash to me... It looks like the OS is putting up a dialog informing the user of an MSAL auth attempt that is using ASWebAuthenticationSession? Is there any particular reason that you chose to use ASWebAuthenticationSession over WKWebView? If you do need it, have you enabled the SafariViewControllerBlockedOverride setting in the Info.plist as mentioned here? Also, just wanted to point out that there is potential for data leak when using this flag, as mentioned in the linked section above.

[KyLeggiero]

@Kyle-Reis it is a crash. The above screenshot is the last app state before the crash. Without the debugger, the app disappears and Springboard is shown. With the debugger, it pauses here in main, reporting SIGABRT. Here's a screen recording of this happening without the debugger: https://photos.app.goo.gl/7Gh8vdA5kCNgdWzE7

Here's a crash report file (there are many very similar to this):
Smartcrypt for Intune 2020-09-04, 09-55.crash.zip

Our code never references ASWebAuthenticationSession (nor any other form of web view), but it's referenced a lot in MSAL and IdentityCore, two Microsoft libraries which are required when using this one. Related to choosing particular web views over others: #107

[Kyle-Reis]

@BenLeggiero, Ah, MSAL actually uses ASWebAuthenticationSection by default. Could you try using a WKWebView instead as described here: https://docs.microsoft.com/azure/active-directory/develop/customize-webviews#change-per-interactive-request

[KyLeggiero]

After changing our code to pass params.webviewType = .wkWebView, and that seems to have addressed the crash.

It seems odd to use a discouraged approach as the default. Is there any particular reason that you chose to use ASWebAuthenticationSession over WKWebView?

[Kyle-Reis]

@BenLeggiero, Great to hear the issue is resolved! MSAL and Intune are two separate products, and app developers may integrate MSAL for authentication without integrating the Intune SDK. The MSAL team decided to make ASWebAuthenticationSession the default web view for interactive auth. I'm not sure what their reasoning for doing so was. My guess would be that for ASWebAuthenticationSession, tokens can be cached in the system keychain allowing for SSO between apps from different publishers. In any case, ASWebAuthenticationSession in only discouraged from the Intune perspective, and when the Intune SDK handles interactive authentication (for apps that call our loginAndEnrollAccount method), it does configure MSAL to use WKWebView. So the recommendation for apps initiating their own interactive auth and then enrolling in Intune silently is to not use the default and instead use WKWebView. I'll update our documentation to make it clear that ASWebAuthenticationSession is the default web view used by MSAL and that developers should explicitly use WKWebView in this scenario.