Okta has updated their server side rule for "automatically send push" to be a per-user setting stored in the Okta directory instead of a device based cookie stored on the individual computer.The "unexpected push" happens any time the Jamf Connect menu bar app does a background password check of the user's credentials AND the device is configured to use OktaIdentityEngine as the Provider AND the app defined by OIDCClientID has an Okta Authentication Policy that requires multiple factors for authentication.
What Jamf Connect is doing - Interpret a response from Okta that MFA is required to obtain a token as a valid password. Ignore the fact that we didn't get an access token because we don't need one.
What OKTA is doing - Getting a request to log in on an app that requires MFA, looks at the user's value for "Send push automatically" stored now on the server, sends the user a push notification.
Example graphic below - (Also, this is the only known location in the Okta settings for the user that can "uncheck" the option to "Send push automatically.")
Solutions:
Option one:
This option is the quickest fix BUT introduces another issue. This is "disable MFA" for the app for Jamf Connect. This would disable MFA for Jamf Connect Login, so even though it's fast, I don't recommend it.
A) Find your application in Okta. Go to the Sign On tab, scroll to the bottom, go to User authentication section.
B) Edit this assigned Authentication policy to be a policy that can only use Password.
Option two:
This option is not recommended because it relies on users following instructions.
Find any application gated by Okta with an interactive login. When push is sent to your user, tell them to UNCHECK the box for "Send push automatically" BEFORE accepting the push notification.
Option three:
This option requires the most work on your part but will solve the problem for the long run.
A) Create a new, second application for Jamf Connect following the instructions from https://learn.jamf.com/en-US/bundle/jamf-connect-documentation-current/page/Configuring_Okta_Identit...
B) Assign an Authentication policy that requires password only.
C) Make sure you have the same users assigned to the second application as you would for the first application.
D) In your Jamf Connect menu bar application configuration profiles, update the value for OIDCClientID to be this new app.
RESULTS: For login, the user will be prompted for whatever Authentication rules you've applied to the login screen (MFA, multiple factors, whatever)
Bonus feature - you can now specifically REMOVE certain authentication types from an authentication policy so you can avoid presenting useless options at the Jamf Connect login screen that aren't possible to be used (Fastpass, FIDO2, etc).
The menu bar app will continue doing what it's done all the time - silently check the password every X minutes (default 60) and when the app launches and when the machine wakes from sleep/screen saver.
The access token received by Jamf Connect menu bar is useless - it's access to a web service that doesn't exist, and it's immediately thrown out. No security risks by giving someone a key to a door which doesn't exist.
