Google Chrome, Apple Platform Single Sign-On, the Microsoft Single Sign-On Chrome Extension, and Microsoft Conditional Access. Confused yet?

   August 12, 2026  Leave a Comment on Google Chrome, Apple Platform Single Sign-On, the Microsoft Single Sign-On Chrome Extension, and Microsoft Conditional Access. Confused yet?  Posted in Workspace ONE

I got it wrong. Kind of. In my blogs regarding Apple Platform Single Sign-On (PSSO) I recommended companies deploying Google Chrome Browser on macOS should also install the Microsoft Single Sign-On Chrome Browser extension in order to use Apple PSSO with Microsoft Entra. Well that isn’t technically correct. Let me correct my error.

To enable Apple PSSO there must be a 3rd party app installed on the device that includes the enterprise SSO Plug-in. Your choices today include the Omnissa Intelligent Hub for macOS (Hub), Microsoft Intune Company Portal (ICP) for macOS, or Okta Verfiy for macOS. There are others but they will be ignored. The MDM deploys the Extensible Single Sign-On payload which tells the enterprise SSO Plug-in how to configure itself, and you are done. Bask in the glory of Apple Platform SSO.

But then you open Google Chrome browser and hit a Microsoft site and you get prompted for authentication. That’s not right. Is it?

Apple PSSO establishes the machine identity relationship with Entra but Safari is (or was) the only web browser that understands what that relationship is. Google Chrome didn’t speak Apple PSSO which meant Chrome Browser prompts the user for authentication. At least it used to. Beginning in Google Chrome Browser version 135, Google added support for the Apple Enterprise SSO Extension. Google taught Chrome how to speak Apple PSSO. And then there were no more authentication prompts. Right!!!??? Maybe.

In Microsoft Security Land, the Device Identity established by the configuration of Apple PSSO is only part of the identity story. Microsoft Conditional Access is the additional layer of security. On macOS, the Microsoft Enterprise SSO plug-in delivered as part of the ICP app acts as the broker between the browser, the device identity, and Microsoft Entra. Chrome therefore needs a way to communicate with that Microsoft SSO broker when device-based Conditional Access is involved. Microsoft recommends the complete macOS identity story to be configured like this: 

macOS
 |
 +-- Apple Platform SSO
       |
       +-- Microsoft Enterprise SSO Plug-in
             |
             +-- Company Portal
                   |
                   +-- Safari / supported native applications
                   |
                   +-- Google Chrome
                         |
                         +-- Microsoft Single Sign On Extension
                               |
                               +-- Entra ID
                               +-- Microsoft 365
                               +-- Conditional Access

Once the Microsoft Single Sign-On extension is added to Chrome, the authentication path becomes:

User
 |
 v
Google Chrome
 |
 v
Microsoft Single Sign On Extension
 |
 v
Microsoft Enterprise SSO Plug-in
 |
 v
macOS Platform SSO Identity
 |
 v
Microsoft Entra ID

I was correct in recommending you deploy the Microsoft Single Sign-On Chrome Extension, but I was incorrect for indicating that it’s part of Apple PSSO. It’s not for Apple PSSO – it’s required for Microsoft Conditional Access.

How do you deploy it?

First make sure Apple PSSO is enabled and functional based on the other blogs I published.

Next, in the UEM Console create an Imperative Device Payload using Custom Settings:

<dict>
    <key>PayloadDisplayName</key>
    <string>Google Chrome Policies</string>

    <key>PayloadIdentifier</key>
    <string>com.google.Chrome.policy.forceinstall</string>

    <key>PayloadType</key>
    <string>com.google.Chrome</string>

    <key>PayloadUUID</key>
    <string>12345678-1234-1234-1234-1234567890ab</string>

    <key>PayloadVersion</key>
    <integer>1</integer>

    <key>ExtensionInstallForcelist</key>
    <array>
        <string>ppnbnpeolgkicgegkbkbjmhlideopiji;https://clients2.google.com/service/update2/crx</string>
    </array>
</dict>

And don’t be confused if this looks like garbage, that is not a glitch on this website. The ppnbnpeolgkicgegkbkbjmhlideopiji is Microsoft’s Chrome extension ID (as if XML wasn’t confusing enough already).

Replace the PayloadUUID with your own unique ID before saving the profile.

For the payload assignment, I recommend Manual deployment, not Auto. This payload should only apply to devices that have PSSO enabled AND that have Chrome installed. It’s best to handle this using UEM Freestyle Workflow. the logic flow recommended is this: 

Is Google Chrome installed and sufficiently current?
        |
        +-- NO --> Install/update Google Chrome
        |               |
        |               v
        |          Install Chrome PSSO Profile
        |
        +-- YES --> Install Chrome PSSO Profile

Once this is deployed to a device, Chrome will use the existing organizational identity rather than starting an entirely independent authentication session. In other words, it will work like you thought it should in the first place.

With regards to Troubleshooting, first look to the Microsoft ICP app should something go wrong. ICP includes a Save diagnostic report in the app’s Help menu which will pull the log files from the device needed to troubleshoot.

Leave a Reply