Authentication Errors on Many Third-Party Apps We Have Already Allowed

[coreyjeffers]

We have suddenly been having a number of different 401 authentication errors in a number of applications that have been working for us for a long time. We utilize the KnowBe4 Phish Alert tool and AirTame 2 devices for digital signage. We have had third-party apps set to be not allowed for probably the past 2.5 years, and normally we approve things selectively by obtaining the client ID. None of these errors are limited to occuring onsite or on certain devices or browsers. They exist on school networks, mobile networks, iPhones, Android, Windows, and Chromebooks. We've contacted both Airtame and Knowbe4 separately and had numerous calls. We have chatted with Google support as well. Oddly enough, in the Airtame admin panel, I'm allowed to add an @gmail.com account, so I added my own personal gmail account to see if I could add a Google Slideshow the same way I would with our workspace domain accounts, and authentication didn't fail with my @gmail.com. However, it doesn't seem to matter with workspace account I have try this, they will receive a Google authentication error every time. Has anyone else experienced any strange issues with third-

[Kim_Nilsson]

Interesting, but not heard of anything like this (yet, perhaps).

[coreyjeffers]

It's definitely getting frustrating now. We're up to six tools we used to be able to use and cannot. 

1. KnowBe4 Phish Alert - 401 authenticate error cannot report phishing emails.
2. Airtame - Cannot authenticate to load slides, but can authenticate to login.
3. Pixton - Cannot authenticate to login "Failed to fetch user profile"
4. Peardeck - Cannot authenticate to login
5. Doodle.com - Cannot authenticate to login (502 Error -Cloudflare)
6. Calendly -  Cannot authenticate to login "Oops, something went wrong."

It has to be something on our end, but I cannot figure out what.

[Kim_Nilsson]

Have you reached out to the listed services and made sure they haven't started using new client_ids?

On your own you can go to the Add App button and search for the named service, and see if their client_id is still matching the one you have allowed.

Oh, and don't forget to actually open your currently configured row, and verify that it is actually set to Trusted or Limited (depending on your setting of Google Services) for the OUs where your users are.

Remember that you may have set different access levels in different OUs.

Do NOT click the Change access button as that will not show you your current access level, only let you set a new access level.

[coreyjeffers]

Thank you for these suggestions. I have reached out to KnowBe4 and Airtame. I've provided HAR files to both support teams and fiddler captures. I have gone over the Client_IDs, and I've set them to trusted.

This is a terrible idea, but I honestly went into allow ALL third-party apps for more than 24 hours to see if that would resolve the issue, and it didn't work for any of the apps on the list. Still receiving the same errors. Replying here because I went to the companies and escalated the cases, and I have cases open with Google about this, too. Google keeps on telling us its the third-party, but again @gmail.com accounts can authenticate just fine.

The strange thing is that PearDeck, which we actually pay a subsription for and have a data privacy agreement, has a screen indicating that Google is having issues with Login. 

Thanks for the suggestions. Really feeling helpless and at a loss.

[coreyjeffers]

Adding to my own post. Screencastify is now added to our list.

KnowBe4 seems to think that our admin panel seems to be blocking valid oauth tokens. Not sure exactly what this means but it is awful to be in education and not allow people to login to verified applications that we've paid subscriptions for because there is no other way to login other than with Google.

[Kim_Nilsson]

For debugging purposes, have you removed a previously trusted client_id and then re-added it again?

Obviously with some time in between, so the system recognises the change before trusting it again.

[coreyjeffers · Accepted solution]

The solution to this was being certain that context-awareness settings were consistent for every allowed app. Many of them needed to call up something outside the US, and we didn't allow logins outside the US. Thus, the apps were being blocked. 

[Kim_Nilsson]

Ah, that's a great find. Thanks for updating us.