It's all very simple: Entra* (Azure AD or however you'd call it) should not be used for AuthZ. Entra AuthN is okayish, but forget about Entra AuthZ, do it all yourself. It's all very simple to avoid once you do AuthZ.
* No idea why the rename happened. Does some manager in Microsoft have the plaque: "Renomino, ergo sum."?
It's ok to use Entra for AuthZ. Just click the box that says "Require users to be assigned to this application" and assign them [1]. However - that's really the only AuthZ feature Entra has. If you don't enable AuthZ, you should not expect Entra to just magically do AuthZ for you.
Edit: I would add - simple allow/deny authz is only relevant for the very simplest of apps (where all users have the same permissions). For any complex application, users will have different levels of access, which usually requires the application to do AuthZ.
[1] https://learn.microsoft.com/en-us/entra/identity/enterprise-...
>For any complex application, users will have different levels of access, which usually requires the application to do AuthZ.
Any application when AuthZ isn't simply yes/no, which rather quickly is just about all of them (even simple blogs have an admin tier), except for a very heavily microservice based architecture - where one would still want to have a much more convenient interface than Entra to see/manage the access permissions centrally... Entra AuthZ is at best a temporary development aid, but it's so easy to roll AuthZ yourself one might as well do it.
IMO “Azure AD” implies it is literally just AD hosted in Azure, when it’s become much more than that