Jamf Connect Login window loop after successful 2FA

I am also running into a similar loop, slightly different.

I have Connect Login setup and it is asking for my Azure credentials. I type them in, get the screen asking if I want to stay signed in to reduce logins, Select Yes (or no), the screen goes black for a minute and then goes back to the first screen asking for the username.

It is showing a successful sign on in Azure Jamf Connect app, then showing "interrupted" a few seconds later. All the settings look correct from the documentation I have read.

Anyone else have this issue before? We do have MFA, but I have disabled it for testing on this account.

Did either of you ever get this resolved?

I would also like to hear a response, as I am experiencing this same problem now. 6 months after the last post on this thread.

Has anyone figured this out yet?

When logging in make sure that the proper browser is selected and that the browser plugin is installed and active.

I've witnessed this looping behavior occur if the IdP is waiting for the Jamf Connect Login client to provide the key

<key>OIDCClientSecret</key>

as part of the authentication process. While the error log may specifically call out "body must contain the following parameter: ‘client_assertion’ or ‘client_secret’", the log may also return error code 401 despite Azure logging the authentication as successful.

I'm experiencing this issue in Jamf Connect 2.0. FV2 was ON and individual recovery keys were escrowed to JAMF.

Having the same issue on Jamf Connect 2.0. Using the same settings in a new configuration profile as with Jamf Connect 1.xx (where it is still working fine), but it keeps redirecting me back to the login page. I did notice you can login with a local account, while that actually should not work as it is not enabled in the configuration profile, aside from the fact that I'm authenticating to my IdP. Setting your client secret should not be necessary if you've set that option to "Use PKCE" within your IdP, so that shouldn't be the cause..

Update: I got it fixed. Had to set the “Require Network Authentication” key to “True” in my JCL's config profile and now it's not in a loop anymore.

I am also experiencing this issue trying to authenticate via Okta. I get the prompt for MFA and after completing it, the screen refreshes back to the JCL screen.

Having the same issue on Jamf Connect 2.0. Using the same settings in a new configuration profile as with Jamf Connect 1.xx (where it is still working fine), but it keeps redirecting me back to the login page. I did notice you can login with a local account, while that actually should not work as it is not enabled in the configuration profile, aside from the fact that I'm authenticating to my IdP. Setting your client secret should not be necessary if you've set that option to "Use PKCE" within your IdP, so that shouldn't be the cause.. Update: I got it fixed. Had to set the “Require Network Authentication” key to “True” in my JCL's config profile and now it's not in a loop anymore.

I have tried setting DenyLocal to true but the issue persists.

I am also experiencing this issue. Tried DenyLocal to true also but the issue persists here also. Tried using Use PKCE and setting a client secret and neither seems to change the behavior. Using Okta as the iDP.

I am late to the party. Think the issue is related to having AuthServer & OIDCAuthServer filled out. What I did with the Jamf Connect Config, is just leaving OIDCAuthServer blank and only fill out the Auth Server. If you're using a .plist is just have only AuthServer & get rid of <key>OIDCAuthServer</key>

I'm seeing this with 2.1.1 and Okta, but I don't have the OIDCAuthServer key set, and still get this...

This is my .plist, which it's working fine with 2.1.1, so maybe check if you're missing one key or try and use the same setup?

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0"> <dict> <key>AuthServer</key> <string>xxx.okta-emea.com</string> <key>BackgroundImage</key> <string>/usr/local/images/xxx.jpg</string> <key>CreateAdminUser</key> <true/> <key>DenyLocal</key> <true/> <key>EnableFDE</key> <true/> <key>HelpURLLogo</key> <string/> <key>LocalFallback</key> <false/> <key>LoginLogo</key> <string>/usr/local/images/xxx.png</string> <key>LoginScreen</key> <true/> <key>OIDCClientID</key> <string>xxxxxxxxxxxx</string> <key>OIDCDefaultLocal</key> <false/> <key>OIDCIgnoreAdmin</key> <true/> <key>OIDCProvider</key> <string>Okta</string> <key>OIDCRedirectURI</key> <string>xxxxxx</string> </dict>
</plist>

Update - I ran into this issue and worked with Support. Oddly enough, removing any entries not being used in the Config Profile resolved this issue for us with JamfConnect Login and JamfConnect. I would suggest edit the config profile, erase and re-enroll your test device to fully test.

Thanks for this, resolved my issue. 

Not trying to resurrect a dead thread here, but we're running into the same issue. And I'm wondering what you mean by: "removing any entries not being used in the Config Profile"

We can't for the life of us figure out why the login loop is happening. We've stripped our plist to barebones (just provider/auth server/access ID) and it's still happening. Funny thing is, if we remove the access ID and instead replace with the Admin ID, it works. So it doesn't like something about the access ID even though that Application is setup identical to the Admin one in Okta (aside from the actual ID of course).

@AdamM01 Removing any entries not being used in the config profile means by de-selecting them / unticking them, so they won't become visible as an empty setting in the plist. Also, is your "“Require Network Authentication" key set to True?

Experienced the same issue. 

Worked:

Removing the access ID from the .plist and only using the Admin ID. 

I will test a new config profile and create it for the access ID. 

The redirect URIs need to be the same! (Solution) Based on the training video it had diff ones

Yes, it was. We actually figured it out, we had to add this entry into our plist:

<key>OIDCRedirectURI</key>

<string>https://127.0.0.1/jamfconnect</string>

Jamf tech we were working with didn't mention this and we didn't see anything in the docs indicating this. But after entering this info, it worked.

Yeah, we were missing this entry in our plist, which fixed the issue.

<key>OIDCRedirectURI</key>

<string>https://127.0.0.1/jamfconnect</string>

I know I'm late to this party. We are authenticating to Azure/O365 and occasionally see this as well. Sometimes it's as simple as switching to different internet like a hotspot and then it connects and authenticates again. I've certainly looked at all of the suggestions here as well. I have been able to log in and create a new account when other existing accounts aren't working. My most recent fix was to delete the user account and leave the home folder in place then sign in with the user's email address let it create the new account and find the old home folder. Fortunately all files and apparently user preferences were there afterward. In my case it appears there was some corruption in the local account. I think the same symptoms we see on the login loop could have multiple causes. Hope this helps someone in the future!