A quite common error, actually. Lots and lots of services are configured to accept logins from arbitrary auths, but forget to verify that it's an auth they actually trust! You just check that it's a valid oauth token, and your code works for your login page, so you consider your login-feature to be done and move on to something else, leaving a wide open door.
Edit: As the article itself stated, around 25% of all systems with this setup are vulnerable!
> The results surprised us: 25% of all the multi-tenant apps we scanned were vulnerable to authentication bypass.
If only. How about: just download the backup of the server log from https://example.com/logfile.txt? Oh, and it contains everything. Including internal application logs.
Btw, even single-tenant can be a bit scary in this regard: You can by default log in with guest users. For instance if someone has joined a teams meeting. So unless you explicitly check permissions or disable this (for instance if you think "everyone in our org should have access to this"), you inadvertently could have external people log into your apps as well.
Tutorial on how to deny Guest users in Azure AD[1]
In general, one should always use roles in Azure. Even if you have a flaw like this, your endpoint would be safe if you required a role to access your endpoint.
For multi-tenants, I completely this misconfiguration, there’s no real warnings when configuring it. In order to lock down to specific tenants, I recommend having a list of issuers that you check the token against.[2]
Edit: As the article itself stated, around 25% of all systems with this setup are vulnerable!
> The results surprised us: 25% of all the multi-tenant apps we scanned were vulnerable to authentication bypass.