Skip to main content

Hello all,

I’ve run into a couple of issues I’m looking for solutions for with Automox’s implementation of SAML, one of which is a security concern.

 

Scenario 1: You have an Entra joined Windows device that you log into with an Entra ID account (joel@contoso.com). Once logged in, you open up a fresh copy of Microsoft Edge with no stored credentials, cookies, or cache. Finally, attempt to log into Automox. 

 

Expectation: Edge will use your device credential by default to SSO authenticate you into Automox, if that is rejected, you will be prompted to create a browser token via Microsoft to authenticate to Automox. 

Reality: The device credential created by Edge is rejected by Automox, no attempt is made by Automox to request your computer create a browser token, and there is no way to prevent Edge from using your device credential in the browser.

Result: You simply cannot use Edge to log into Automox in this circumstance unless you use an incognito window.

Scenario 2: You have a regular account and an admin account for Entra. In the browser, you are signed into your admin account (admin_joel@contoso.com). You attempt to log into Automox in that browser, but your Automox login is your regular account, so you attempt to log in with your regular account.j


Expectation: You put joel@contoso.com into the username field of Automox, you click next, and you are prompted to log into Microsoft to create a browser SSO token because one doesn’t exist for that account in the browser you’re using.

Reality: Automox will confidently ignore the email address you put in the field and immediately attempt to use whatever Entra SSO token already exists in the browser and then tell you that admin_joel@contoso.com isn’t allowed to log into Automox.

Result: You simply cannot use this browser to log into Automox unless you clear the cached credential from any other Entra account that is stored in the browser.

Here is the security concern with scenario 2: If the account whose token is stored in your browser has EVER been allowed to use Automox via SAML in the past, even if the account no longer exists in Automox and isn’t currently in any groups connected to the Automox SAML enterprise app in Entra, if you type in the email address of an account that should be able to use SAML to log into Automox, Automox will instead create a credential for the account associated to the active token in the browser instead.

admin_joel@contoso.com is in Automox_users which is connected to the Automox SAML application in Entra for constoso.com

You use admin_joel@contoso to log into Automox using SAML

You then use a different account to delete the admin_joel@contoso.com user from Automox.

You remove admin_joel@contoso.com from Automox_users

At some later point, you add joel@contoso.com to Automox_users

You sign into a microsoft website (entra.microsoft.com) as admin_joel@contoso.com creating a cached token for that account in the browser.

You then go to Automox’s website and try to login using joel@contoso.com 

Result: Automox will see that joel@contoso.com is allowed to log into Automox using SAML, but Automox won’t prompt for a new token for joel@contoso.com, instead Automox will attempt to use whatever Entra token is already stored in the browser (admin_joel@contoso.com) and if that user has ever in the past been approved to use SAML to log into Automox, then Automox will create a read-only account for that user today, even if the user isn’t currently in any group that would approve it for login using SAML.

Hi ​@joelv, 
The behavior you’re seeing stems from how Microsoft Entra (Azure AD) and Edge manage cached authentication tokens rather than Automox directly overriding your chosen login. When you initiate SAML authentication, Automox relies on the IdP (in this case, Entra) to determine which token to use. If a cached Entra session/token exists in the browser, Entra automatically supplies it, even if a different username is entered at the Automox login prompt. Automox never receives the opportunity to request a new token for the alternate account.

  • In Scenario 1,Edge defaults to the device credential and does not give Automox a chance to request a browser token if that fails.

  • In Scenario 2, the browser/Entra combination always provides the existing cached token, preventing Automox from prompting for a new login.

  • The security concern you highlighted is also tied to token reuse: if Entra still honors a cached token, Automox receives it as valid. To prevent this, the token needs to be invalidated/revoked at the IdP level.

Workarounds available today:

  • Use an incognito or a different browser when logging in with a different account.

  • Clear cached Entra tokens/cookies in the browser before switching accounts.

  • Ensure stale accounts are fully disabled/removed in Entra and their tokens revoked, so they cannot be reused.

We’ll also pass this along internally as feedback, since the outcome does impact the Automox login experience and we want to ensure the security posture is as strong as possible.
 

For further assistance, you can:

  • Reach out to our Support team via help.automox.com for in-depth troubleshooting and triage.

  • Set up an enablement session with your CSM to walk through configuration best practices and help optimize your SAML setup.
     

I hope this helps, have a great day!
 

Hey ​@JohnG-Automox,


Thanks for following up with me on this.

For the primary issue from scenario one, I did some digging around related to your response and it looks like this is something Automox could fix by changing the RequestedAuthnContext requirements on your side. Changing it to some combination of acceptable types that includes x509 device based credentials. I understand if that is something that Automox isn’t looking into, but it does seem like an inevitably determinate problem since the number of companies migrating to Entra ID only for their devices is going up and companies move away from on-prem active directory which is going to increase the number of people using Edge with a device generated credential. 

Scenario 2 experiences much of the issues of scenario one, however, the workaround you posed:

  • Ensure stale accounts are fully disabled/removed in Entra and their tokens revoked, so they cannot be reused.

Only solves part of the problem. From what I can tell, this issue exists for any current employee who has ever connected to Automox in the past using SAML and only requires that the employee be properly logged in to Entra ID and type in the name of a user who currently has access to Automox. The impact in this case is limited because the account is created as read-only, but even if I delete it, the user could just create it again, and I’d like to see a future where Automox allows automatic role provisioning.

Reply


Terms & ConditionsCookie settings