Issue description : When a device is newly Intune enrolled in A14, the user is able to login to Defender, but unable to retrieve the pop access token. As a fallback, Defender allows onboarding without pop token (which is why you were able to onboard fully to Defender). However, in absence of the correct token Defender backend does not acknowledge heartbeat calls we send every few hours to maintain device compliance. Heartbeat failure subsequently fails the signals being sent to Intune backend marking the device non-compliant (Device_Threat_Health_Not_Reported reported by Intune).
This is an issue especially when policies are setup to make the device noncompliant if Defender is not setup (this is what Microsoft has setup internally).
Current fix : After I raised this issue with google, they suggested that we should reduce the keyParameters and try. By removing the encryption paddings, the issue seems to be resolved. Also checked with Amit and it seems we are not doing any encryption or decryption using the key pair generated. We are only signing. So, I also removed some of the purposes like VERIFY, ENCRYPT and DECRYPT. While I am still following up with them on why it is specifically failing on Android 14, I have applied the fix they suggested.
Testing : Tested with MsalTestApp with AuthScheme as POP and verified that acquireToken interactive and silent flows are working as expected. Also, I ran the UI tests for POP.
Note : This fix is yet to be verified by Defender team.
Issue description : When a device is newly Intune enrolled in A14, the user is able to login to Defender, but unable to retrieve the pop access token. As a fallback, Defender allows onboarding without pop token (which is why you were able to onboard fully to Defender). However, in absence of the correct token Defender backend does not acknowledge heartbeat calls we send every few hours to maintain device compliance. Heartbeat failure subsequently fails the signals being sent to Intune backend marking the device non-compliant (Device_Threat_Health_Not_Reported reported by Intune).
This is an issue especially when policies are setup to make the device noncompliant if Defender is not setup (this is what Microsoft has setup internally).
Bug link : https://identitydivision.visualstudio.com/Engineering/_workitems/edit/2574078
Previous temporary fix : https://github.com/AzureAD/microsoft-authentication-library-common-for-android/pull/2053 The fix in the PR above was only to catch the exception and swallow it and skip trying to use strong box for key pair generation.
Current fix : After I raised this issue with google, they suggested that we should reduce the keyParameters and try. By removing the encryption paddings, the issue seems to be resolved. Also checked with Amit and it seems we are not doing any encryption or decryption using the key pair generated. We are only signing. So, I also removed some of the purposes like VERIFY, ENCRYPT and DECRYPT. While I am still following up with them on why it is specifically failing on Android 14, I have applied the fix they suggested.
Testing : Tested with MsalTestApp with AuthScheme as POP and verified that acquireToken interactive and silent flows are working as expected. Also, I ran the UI tests for POP. Note : This fix is yet to be verified by Defender team.