There is a common misconception around AAD apps. If you can see it in myapps, you have access to it – otherwise you do not.
This is not entirely true. In fact, by default, an AAD user may still be able to get to an app via it’s direct link (deep link 0 e.g. myapps.servicenow.com).
AAD – TWO Attributes that define Access Level
To map to the two cases outlined above, Azure contains two separate attributes.
UserAssignmentRequired and VisibleToUsers
AAD Guest Users and Default Access
Guest users are typically added via invitation emails or invitation direct links. (There is a backdoor way to add them using Powershell and Graph API).
What enterprise apps guest users have access to depends on the configuration of the service itself. Sharepoint Online may be set to ALLOW all guest users – and this would let in ANY guest user added to that AAD.
Guest Users also come in two flavors – True GUESTs and COLLABORATORS
Any EXTERNAL user is automatically of Type = GUEST (even if you mark it as a collaborator).
In order to be a true collaborator, the IdP that they are coming from needs to be trusted within the AD that contains your true internal users (corporate users)
Summary
It is easy to miss some of these nuances around AAD and Enterprise Apps within AAD. Not accounting for these could open up some of your internal services (sharepoing, onedrive…) etc. to unauthorized users.
Need an experienced AWS/GCP/Azure Professional to help out with your Public Cloud Strategy? Set up a time with Anuj Varma.