Configuration for IdPs using OpenID Connect

You can configure the loginwindow by setting preference keys in Jamf Connect Login. The following preference keys can used with identity providers (IdPs) that are using OpenID Connect (OIDC):

  • Microsoft Azure AD

  • Google Identity

  • IBM Cloud Identity

  • OneLogin

Preference keys allow for full manipulation of Jamf Connect Login’s features. You can set preferences through multiple methods:

  • Create a new configuration profile in your MDM solution

  • Install a configuration profile locally

  • Set manually with the defaults command


  • The defaults command will not show preferences set by an MDM solution.

  • Required and configurable preference keys may vary for each IdP.

Jamf Connect Login preference keys must be written in the following location:



  • Jamf Connect Login does not create this .plist file. You must create it manually, use the example provided in the Jamf Connect download, or the example provided by your account manager.

  • If using Jamf Pro, you must sign the configuration profile before uploading. For more information, see the Deploying Custom Configuration Profiles with Jamf Pro Knowledge Base article.

The following is an example of a .plist file that can be used to configure Jamf Connect Login with IdPs using OIDC:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
<plist version="1.0">

Preference Keys

The following tables contain all the preference key-value pairs used with Jamf Connect Login for IdPs using OpenID Connect.

Note: Boolean key-values that are not configured default to false.

Required Key-Value Pairs





Specifies the IdP provider integrated with Jamf Connect Login




Redirect URI used by the added app (Jamf Connect Login) in your IdP




The Client ID of the added app in your IdP used to authenticate the user. This value should match the OIDCROPGID key.




The Client ID of the added app in you IdP used for authenticating the user's password via a resource owner password grant (ROPG) workflow. This value should match the OIDCClientID key.

Note: Google ID does not support ROPG workflows.



Optional Key-Value Pairs






If set to true, the user must create a new password on the computer

If set to false, the user must validate with their existing IdP password, which will also become the local password.

Important: If using Google ID as your IdP, this key must be set to true.




Determines which roles become an admin at the loginwindow. Users assigned a specified role become an admin at the loginwindow. You can also specify an array of strings to list multiple users














The attribute in the user's SAML ID token used to determine if they are an admin user or not.




Specifies the IdP Tenant to use for authentication.




Determines if FileVault is enabled for the first user to sign in




If set to true, Jamf Connect will store the FileVault recovery key to /var/db/NoMADFDE unless otherwise specified




Specifies a custom path for the Recovery Key




Specifies the path where the end user's license agreement record (EULA) is stored.




Text used for the EULA


<string>Insert EULA text here</string>


Title of the EULA text


<string>User Agreement</string>


Subtitle of the EULA text


<string>Terms and Conditions</string>


Path to an image to use for the background of the login screen




If set to true, all users become local admins when created on the computer




Determines if mobile accounts should be demobilized




Ignores any cookies stored by the loginwindow




The contents of a .jamfconnectlicense file encoded in Base64 data format




Path to a locally stored image file used for the logo during password validation or local password creation





Text displayed when a user must enter a one time password (OTP)


<string>Enter your verification code.</string>


Allows local accounts to be migrated to Okta-based accounts.

This is typically used when the user account was already created on the system, but you want the accounts to have the same username and password as the user’s Okta identity.

Jamf Connect Login does this by forcing the user to sign in via Okta, and then attempts to match the user with an existing local account. Consider the following user migration scenarios:

  • If a user's Okta username and password match a local username and password, the account is considered migrated. No additional steps are needed.

  • If a user's Okta username matches a local username but the passwords do not match, the user will be prompted to enter their current local password. Once successfully entered, Jamf Connect Login will use the current local password and the current Okta password to sync the account to the current Okta password.

  • If a user's Okta username does not match any local account, the user will be given the option to create or migrate a local account. To migrate an account, the user must provide the existing local password. At this point Jamf Connect Login will synchronize the password to the Okta password, and then add the Okta username as an alias to the local account. This way the user can sign in to the system as their Okta username.

Additionally, Okta can migrate users from local accounts to accounts associated with an Okta identity. With the Migrate and DenyLocal preference keys, all subsequent sign-ins will be authenticated to Okta, and then the system verifies if the user record has an “OktaUser” attribute. If this attribute cannot be verified, the user will be asked to select a local account to associate with the user’s Okta account. If the local account shortname does not match the Okta shortname, the Okta name will be added as an alias to the account so the user will be able to use either one. This also keeps the home folder path and other elements of the user record the same.

Note: For every successful Okta authentication of a user, the user’s record will be updated with the “NetworkSignIn” attribute. If the user was only authenticated locally, this attribute will not be updated.




Determines if users can bypass network authentication and use the Local Auth button at the loginwindow.

If set to true, the Local Auth button is not available, and user must authenticate to their network.

If set to false, the Local Auth button is available, and users can choose to authenticate locally.




Specifies which users can still locally authorize if DenyLocal is set to true









When using the AuthUI rule, determines if the token cache is set to /tmp/cachedata



Defaults Command

For testing purposes, the defaults command is useful for manually reading and writing the current Jamf Connect Login preferences.

Note: Commands should be executed as the root user or with the sudo command.

The following are examples of commands you can execute to set Jamf Connect Login preferences.



sudo defaults read /Library/Preferences/com.jamf.connect.login.plist

Shows all current preference key-value pairs set for the application.

sudo defaults write /Library/Preferences/com.jamf.connect.login.plist EnableFDE -bool true

Enables FileVault, if possible.

sudo defaults delete /Library/Preferences/com.jamf.connect.login.plist EnableFDE

Disables Filevault

Note: The standard install of Jamf Connect Login does not include the /Library/Preferences/com.jamf.connect.login.plist file. It must be created with the defaults command or as a configuration profile.

Disabling and Re-enabling Jamf Connect Login with OIDC

You can disable then re-enable Jamf Connect Login with your IdP by executing the following commands:

Disable: authchanger -reset

Re-enable: authchanger -reset -OIDC

Note: When disabled, the default macOS loginwindow will appear to users.

Related Information

For related information about Jamf Connect Login, see the following sections of this guide:

Copyright     Privacy Policy     Terms of Use     Security
© copyright 2002-2019 Jamf. All rights reserved.