When an app is launched on a registered device, a call is made to a MAS protected endpoint. In some cases, the device cert is not being passed to server side, causing the app to receive an error. Customers who experience this behavior are unable to use the app until they delete and reinstall it again.
In this scenario, an error code 103 is raised.
There have been extensive investigations proving that the the device cert is not being sent in the request. What could be the root cause?
Comparing logs with a working app, there are some key differences:
- on the "bad" device, the oauth token detail in logs has "grant_type" = "client_credentials" whereas the "good" device has "grant_type" = password
- on the "bad" device, the oauth token doesn't have an id_token, whereas the "good" device is granted an id_token
MAS 2.4 on iOS
The root cause is related to the iOS Keychain:
|<< [MAS] >>>| 2024-07-29 11:20:21.996 IST | DEBUG | MASSecurityService.m:217 | -[MASSecurityService createUrlCredential] | >>>
{
called and identities is: (null) and certificates is: (
"<cert(0x10b7668c0) s: 1560544821 i: ca_msso>",
"<cert(0x10b766ee0) s: 1560544821 i: ca_msso>",
"<cert(0x10b7674f0) s: 1560544821 i: ca_msso>",
"<cert(0x10b767b00) s: 1560544821 i: ca_msso>",
"<cert(0x10b768120) s: 1560544821 i: ca_msso>"
)
}
The MAS SDK is unable to extract the client certificate identities (kSecClassIdentity) for a certificateLabel(kSecAttrLabel) but is able to extract various tokens and certificates successfully.
PFA the updated SDK with a strong reference for NSURLSessionTask for AppDynamics fix.
This fix will be included in the MAS 2.5 release.