Hey folks, so I figured out what was doing this in our environment.
If your org setup checks all of these boxes, this comment will most likely be your fix:
- 365-based Office subscriptions for individual users (i.e. Office licensed with users' accounts and not a generic account)
- 2-factor authentication for 365 accounts
- A timed password reset policy (i.e. reset every 90 days)
- Windows 10 computers (side note for Win7/Win8 at the end)
There is a long-standing issue with Azure/OAuth tokens in Windows with 2FA-enabled accounts when users hit "Yes" to the "Use this account everywhere on your device" prompt when signing into any Microsoft service. What happens is that their 365 account gets added to the "Work or School accounts" section of Windows 10 as well as being signed into Office or whatever other Windows 10 app they are using. This is fine until the password resets, and then what happens is that the main application that is being used (i.e. Office) calls out for a new credential, but the Work or School account entry does not have the ability to do so and instead creates a conflict with any applications that are trying to reach out for a new credential. This will generate the common "Outlook TPM error" in which Outlook tells you that your Trusted Platform Module hardware chip has failed (lies). It can also cause a more vague issue where Office apps ask for credentials but won't let you put them in. This specific thread however, is a more spicy take on this issue. This specific issue is the same as above except that the account entry is hidden from Windows and can only be found and removed from inside of the specific Windows 10 app that the user signed into. More info below.
To fix the generic Azure/OAuth token issue in Windows, we would have to remove the Work or School account from Windows settings like so:
Start > Settings > Accounts > Access Work or School > Click on the 365 account entry > Remove > Ignore warning > Sign back into Office or whatever application was failing before > Choose "This app only" at the "Use this account everywhere on your device" prompt so that it doesn't happen again.
Immediately afterwards authentication will start working again... Unless you're having the specific issue with error: "AADSTS9002313: Invalid request. Request is malformed or invalid" when trying to log in to Office, which means that there might be another secret Work or School account entry hidden somewhere else in Windows.
What I needed to do for this specific issue was search through every non-365 Microsoft app (i.e. from the Microsoft store) that the person used to see if any were still signed in after purging the other Work and School account entry in the location mentioned above. Eventually I found that the OneNote app that comes built into Windows 10 was the culprit. There is a separate "Account" section inside of the OneNote app that had the authenticated/failing Work or School account entry and for some reason that account only showed up in the OneNote app and NOT in the Windows 10 settings. I hit "Sign Out" for that account from inside of the OneNote app and the second that failing account entry was removed the issue immediately went away.
This is a very specific issue, but in my experience many orgs are setup like this nowadays so it might be more common than it would seem at first glance. I hope this info helps someone out there.
If you are using Windows 7 or 8, you'll still want to check on all Microsoft apps to make sure none of them are stuck failing sign in (because they will work similarly regardless of Windows version), however you may instead need to clear credential manager entries to get this same effect. While some builds of Windows 8 have something similar to the account settings mentioned above, it will be good to keep in mind that older versions of Windows heavily relied on the credential manager for this sort of thing. If your org isn't set up with the settings mentioned at the beginning of this post, this info could still be helpful, but your results will most likely vary greatly.