Recently, I was working with a new client who is having issues with Azure AD/Entra Conditional Access. Essentially their issues stemmed from requests on iOS devices that were missing device information when authenticating to Microsoft services. Historically, AAD-CA has never been the easiest Microsoft tech to comprehend or work with. This is something I was pretty familiar with from my work on AAD-CA integration with WS1. Microsoft’s article here is a great example of that as it reads a little bit like War and Peace. Today’s we’re going to talk about what the Microsoft Authentication Broker is, the requirements around it, and how you implement it on iOS. Let’s get started!

What Exactly is the Microsoft Authentication Broker?

I am no stranger to reading the Microsoft Protocol Documentation like I did when I wrote one of my first ever articles on ActiveSync. Sadly, it was not that easy, so we had to dig a bit deeper to get a better understanding.

Authentication Brokers satisfy a few needs for Microsoft services in this context:

• Remove the needs for handling refresh tokens
• Simplify user authentication flow and drive consistency
• Extend more complex authentication flow capabilities like conditional access, FIDO, and more (e.g. device registrations)

WAM (Web Account Manager) is a great example of this in Windows 10+ that we have been using for a long time and don’t realize it because of how synergistic it is within the operating system. It’s basically what handles our connected Microsoft accounts, so no big surprise there:

Developers leverage the MSAL (Microsoft Authentication Library) to get access tokens and interfaces nicely with WAM sort of like how you use Modern Authentication with PowerShell today and run away from that evil Basic Authentication. A nice code example of this can be seen below:

BrokerOptions options = new BrokerOptions(BrokerOptions.OperatingSystems.Windows);
options.Title = "My Awesome Application";
options.ListOperatingSystemAccounts = true;

IPublicClientApplication app = 
    PublicClientApplicationBuilder.Create("CLIENT_ID_YOU_HAVE")
    .WithDefaultRedirectUri()
    .WithParentActivityOrWindow(GetConsoleOrTerminalWindow)
    .WithBroker(options)
    .Build();

var authResult = await app.AcquireTokenInteractive(new List<string>() { "User.Read" })
    .ExecuteAsync();

So, now you’re like WTF is MSAL? That is why I’m here, to talk about that too!!

What is the Microsoft Authentication Library (MSAL)?

Simply, MSAL is what lets an application developer get a “security token” to authenticate for users and access the secure APIs like Graph. Because I hate random terms, a common example of a security token would be a SAML assertion. When you’re using OAuth 2.0, which is common in machine-to-machine communication it could have access tokens, ID tokens, and refresh tokens. Microsoft has a great article on tokens here that is super valuable. Just a quick refresher on tokens before we move on is in order.

Microsoft Auth 365 Tokens

We have 3 types as I mentioned above:

• ID token
• Access Token
• Refresh Token

The ID token(token that tells you about the user) looks like this when you decode the JWT (Java Web Token):

We have Access Tokens, which literally grant you access to protected resources. You can decode your JWT and get a good idea of things. The Access Token will typically have a lifetime of 60-90 minutes. Fun fact is when you don’t have conditional access of two hours for standard apps like Microsoft Teams. You can take things a step farther and configure the token lifetime:

Import-Module Microsoft.Graph.Identity.SignIns
Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod, Policy.ReadWrite.ApplicationConfiguration, Policy.ReadWrite.TrustFramework"

$params = @{
    definition = @(
        '{"TokenLifetimePolicy":{"Version":1,"AccessTokenLifetime":"8:00:00"}}'
    )
    displayName = "Synterex token lifetime policy"
    isOrganizationDefault = $true
}

That command will set it to be the default, but you can also set that to false and use the New-MgApplicationTokenLifetimePolicyByRef command to link it to an existing application.

The last token is the refresh token, which has a lifetime of 24 hours for a single-page application and 90 days for other applications. Those lifetimes are not changeable, but they can be revoked. This is a neat table that outlines those scenarios:

Additionally, application owners can build their applications to revoke the refresh token as its not automatically revoked outside of these scenarios above.

Now, that we have the basics, we turn our attention to the Microsoft Authentication Broker for iOS, Microsoft Authenticator.

Microsoft Authenticator for iOS

iOS devices are unique in that they are the only platform that requires a different application to act as an authentication broker (Android can use Company Portal and Windows can obviously use WAM). The broker application will actually use something called the PRT or Primary Refresh Token to get access tokens for apps and resources secured by Entra.

The very interesting thing about PRTs is only registered devices can get them. The PRT itself is valid for 14 days provided the device is being actively used. Based on what is known, I believe private keys are generated and stored in the secure enclave, while public keys are sent over to Entra ID during device registration. The PRT documentation doesn’t actually reference Apple, but some documentation references the PRT so its somewhat theoretical.

This great graphic by Microsoft below paints a nice picture in a common use case of securing Exchange Online outside of the Outlook Mobile application.

Basically, this shows when combined with that conditional access policy, it will send you to the Apple App Store to get your broker app if needed, which is used to register the device in Entra ID. A few of the things that Microsoft Authenticator does is:

• Brokers elevated authentication for iOS devices e.g. Conditional Access or MFA
• Registers devices in Entra ID similar to how a Windows device is Entra ID-joined

These are some of the great examples of what this application can deliver to you and is an implicit requirement with conditional access.

Setting up Entra Conditional Access for iOS

Now, let’s discuss how you get Entra Conditional Access functional.

The requirements are:

• Integration with the Microsoft Enterprise SSO Plugin
• Microsoft Authenticator Application
• Conditional Access Policies (which we clearly don’t need to cover here)

What is the Microsoft Enterprise SSO Plugin?

The main thing that everyone needs to be aware of is that it’s not just a requirement for people using Entra SSO on their device, but is a strategic component requires for conditional access.

This plugin uses the new Apple platform SSO aka Enterprise SSO to intercept network requests and deliver MFA, tokens, and in this case properly interact with the authentication broker.

Basically, the Plugin will intercept requests going to these URLs:

• https://login.microsoftonline.com
• https://login.microsoft.com
• https://sts.windows.net
• https://login.partner.microsoftonline.cn
• https://login.chinacloudapi.cn
• https://login.microsoftonline.us
• https://login-us.microsoftonline.com

The extension will get access to the URLs, headers, and body by design. The plugin will only support applications uses Apple’s native web APIs like WKWebView for example.

A common setup can be seen below:

This gives you the following:

• device_registration provides just-in-time device registration via Microsoft Authenticator when you launch an application if needed
• browser_sso_interaction_enabled lets you support apps that don’t support MSAL and is required for conditional access to work.
• Enable_SSO_On_All_ManagedApps lets all managed apps use SSO
• disable_explicit_app_prompt lets you use the account picker from the broker when they don’t support MSAL

Final Thoughts

Obviously, there is much to consider when it comes to extended the security capabilities of Entra Conditional Access to iOS. It can be a bit complicated, but once you understand how it works together things make a bit more sense. This is a constantly evolving area for Microsoft so we will have to shift and evolve with it to ensure it aligns with Microsoft and Apple’s strategy so it works synergistically.