The ADAL SDK for Objective C gives you the ability to add support for Work Accounts to your iOS and macOS applications with just a few lines of additional code. This SDK gives your application the full functionality of Microsoft Azure AD, including industry standard protocol support for OAuth2, Web API integration with user level consent, and two factor authentication support.
On iOS, passing in the x-ms-PkeyAuth field in the HTTP header doesn't work for the scenario where the user is first directed to Microsoft sign-in page and then redirected to another adfs sign in page.
ex:
User opens ADAL test app and then attempts to acquire token using OneDrive or Office profile.
user is redirected to Office356 login page (login.microsoft.com)
3)user types in the user id - test@unisys.com
4)user is then redirected to (adfs.unisys.com)
Embedded webview is initialized during step 1, and "x-ms-PkeyAuth" field is added to the HTTP request header.
However, when the user makes it to step 4, "x-ms-PkeyAuth" field is lost in the HTTP header from the server side by then.
This issue can be addressed by appending "PKeyAuth/1.0" keyword to the User Agent string in the HTTP header during the embedded webview initialization/configuration stage. This complies with the PKeyAuth spec and also has been shown to retain the keyword in the User-Agent string field from step 1 through step 4. I have also verified that having the keyword in the User Agent string triggers PKeyAuth challenge using a test account that has device proof CA policy.
On iOS, passing in the x-ms-PkeyAuth field in the HTTP header doesn't work for the scenario where the user is first directed to Microsoft sign-in page and then redirected to another adfs sign in page. ex:
User opens ADAL test app and then attempts to acquire token using OneDrive or Office profile. user is redirected to Office356 login page (login.microsoft.com) 3)user types in the user id - test@unisys.com 4)user is then redirected to (adfs.unisys.com) Embedded webview is initialized during step 1, and "x-ms-PkeyAuth" field is added to the HTTP request header. However, when the user makes it to step 4, "x-ms-PkeyAuth" field is lost in the HTTP header from the server side by then.
This issue can be addressed by appending "PKeyAuth/1.0" keyword to the User Agent string in the HTTP header during the embedded webview initialization/configuration stage. This complies with the PKeyAuth spec and also has been shown to retain the keyword in the User-Agent string field from step 1 through step 4. I have also verified that having the keyword in the User Agent string triggers PKeyAuth challenge using a test account that has device proof CA policy.