Earlier this month I wrote an article on the need to check permissions in tokens: https://joonasw.net/view/always-check-token-permissions-in-aad-protected-api. A week ago I was writing an automated test to check an API we are developing is not vulnerable to this. The test would use an app registered in Azure AD tenant B to get an access token from Azure AD tenant A, and attempt to call the API which is registered in tenant A.
At the time when I wrote the article, it was possible to do this as long as you knew the target application's id and the target tenant id. You would get an access token that is otherwise valid, but doesn't contain any permissions. If the API then didn't check for permissions... Yeah, you can see where that would go.
But the test threw an exception. It was unable to acquire an access token. My first thought was: Great, I must have messed up copying the credentials. But the error message indicated something else:
AADSTS7000217: The service principal named 86c3abcd-abcd-abcd-abcd-abcd19338ccf(Totally Legit App) was not found in the tenant named e67aabcd-abcd-abcd-abcd-abcdf3e75fc5. This can happen if the application has not been installed by the administrator of the tenant.
Wait what?
Well that's different! I was using the v2 endpoint at the time, so I decided to test if the same behaviour also occurred with the v1 endpoint. At that time, the v1 endpoint did give an access token still.
However, that has now changed. Neither endpoint will give you an access token for a tenant where your app has no identity.
But what if we did have an identity in the target tenant? If we could somehow trick a user in the organization to consent to our app, could we do the attack as before? Yes, we could. As long as a service principal for your app exists in the target tenant, you can acquire an access token for any API in that tenant.
So you must still check permissions in tokens. Some organizations may also choose to disable user consent entirely. In that case admin consent will always be needed when anyone wants to start using a new app with their organizational account. So there are pros and cons.
Overall this change is really great. It'll make all APIs secured by the Microsoft Identity Platform that much more secure.