My enterprise organisation utilises OKTA as a SSO service synced from on Premises AD. We are in the process of preparing a JAMF Configuration to roll out to our Mac machines and wipe them so they will use JAMF connect at login rather than normal MacOS Login. I asked OKTA to enable Factor Sequencing for my tenant, this means the authentication flow first works by requiring the user to enter their email address, then the end user presses next and OKTA will do a lookup and look for authentication policies applied to that user. In OKTA you can with Factor Sequencing enabled require both a password and a second factor at long or go a step further and use just one factor like a Webauthn key. In my case I created a policy for our tenant and applied it to our IT team, when OKTA detects a low risk of a malicious attack it will allow the user to login into OKTA using just a factor. When a user is medium risk they are first asked for their factor and then a password. When a user is high risk they are only allowed to login using a combination of factors excluding passwords. My colleague who is building our JAMF connect configuration was testing JAMF Connect, he was using his account to sign into JAMF connect sync. Therefore OKTA did a lookup on his account and found a signon policy which matches his user, it then detected he was low risk so it allowed him to log on to OKTA with just one factor. In this case this works perfectly fine for the standard OKTA web service as it prompts you for your username first, then you click next and then a policy lookup is done and the factors required for signing in are shown. However JAMF connect presents the password box on the same page as the email address box, this causes a conflict. When my colleague tried to sign into JAMF connect sync he was presented with an error along the lines of a stateful operation has occurred. Reason this happened was OKTA detected he was low risk so it let him log on with just a single factor like OKTA verify rather than having to type a password. I then saw his issue and disabled my sign on policy in OKTA. As soon as I done so he could login to JAMF connect. I then turned just the medium risk rule back on, this first requires OKTA verify and then the password however since JAMF connect does not split the factor sequencing it also had the same error. The solution to this would be to segment the email address and password from the JAMF connect sign in, ideally the user would turn the laptop on. Then they would type their email address and then press next, then OKTA will do a lookup and decide how they can log in.