Update 26/08/19: It seems that the "User blocked by OIDC lookup" issue was only linked to a specific Vm creation method (vFuse). I have been able to deploy JCL with Okta without any issues on VM Fusion VM's and physical Macs. Only my vFuse created VM's seem to have the issue. I'm sure I tested with physical machines in the pst, so not sure why the inconsistent behaviour, but it seems fine for me now. Updating the post below now.

Just like in my previous deployments with Azure, I repackaged the official installer, deployed it to a temporary location and add a post-install script to flip the ‘Authchanger’ to Okta.

Don’t forget to put your file permissions!
# install Jamf Connect Login
installer -pkg /tmp/jcl100.pkg -target /
# Enable Jamf Connect
/usr/local/bin/authchanger -reset -Okta
Note: Once again, don't forget to sign you custom package and use a cloud distribution point in case you want to deploy it via a Jamf Pro pre-stage. Both are a requirement for pre-stage packages!
Update! The latest versions of Jamf Connect Login don't need the authchanger to be flipped manually (by tweaking the postinstall script above) anymore. Just rename the official installation pkg to have 'Okta' in the name and the authchanger will be flipped to Okta for you upon installation.

Upload it to your Cloud Distribution point and add the package to your Jamf Pro pre-stage. Next, we need to configure Jamf Connect Login with our settings. Either by writing the settings to a plist with ‘defaults write’, for instance:

defaults write /Library/Preferences/com.jamf.connect.login.plist AuthServer -string "yourdomain.okta.com"

Or by using a config profile. The most basic deployment possible is adding a plist like:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

This, together with the ‘Autchanger’ flipped to Okta, would actually allow all your Okta users to login and create a user account through Jamf Connect Login. This basic setup worked fine for me, and yes, you could probably close it down by adding the optional ‘OIDCAuthServer’ key and create a custom Authorization Server linked to your Jamf Connect Login app (Okta -> Security -> API).

But I wanted to use OIDC and my 2 Jamf Connect Login apps in Okta to leverage the possibility to create Admin users based on the OIDCAdminClientID key.

So I created my 2 Okta apps, one to allow access for assigned users, the other to decide who gets Admin privileges on the Mac…

When creating the app in Okta, make sure you create it as NATIVE app and choose a Redirect URL.

The redirect URL can be anything you want. Jamf documentation advises “jamfconnect://”. Make sure you set the same in the config profile – see below.

Also, after saving the app, hit ‘edit’ and change the ‘Allowed grant types’ – select both option under “Implicit (Hybrid)”

… and assigned my users to both apps. For instance for the basic access app:

Finally, a more advanced plist with some additional options, but most importantly, the OIDCAccessClientID and OIDCAdminClientID keys:

<plist version="1.0">
Note: the OIDCRedirectURI can be anything you want. Jamf documentation says "jamfconnect://". Just make sure you set it the same way you have set it on the app in Okta.