It's a little more complicated - in AAD, the app developer has a single app registration, which is the app side of AAD. The app can ask for certain permissions, specify trusted sign-in URLs, manage client secrets, etc.
Then, on each AAD tenant that wants to use this app, an admin for that tenant would create their instance of the app, called an enterprise application or service principal.
That second object can choose whether any user in that tenant can sign in to the app or not, and can assign AAD roles to users/groups.
It is very common for apps to have a single tenant, and therefor the app registration and enterprise application are both in the same tenant, but if the app registration would allow it, any tenant can create their instance, and assign users from their tenant any role they desire.
This means that it is possible to have an app managed really well within your tenant, yet make the mistake of allowing sign-ins from other tenants, and thereby outsiders could still have full access...
I always loved the AAD documentation whenever I had to work with these things. Whenever I have to implement a service the things I care about are of this nature:
-how do I validate a token to confirm that a call has permissions to do a thing.
-what secrets do I need to safeguard in order to be able to validate said tokens
-does the caller need to store any secrets
-when do I need to call external services in order to validate tokens.
Instead, AAD hides all thrse behind abstract terms like: service principal, app registration, enterprise application... No wonder people fuck up.
I can't even comprehend what "creating their own instance of an app" means! This is way more abstract than it needs to be. Does the code get served from somewhere else? Do they get db copies? Probably not... But it hurts to think in these terms when all we want is to make sure calls are authorized.
And yes, I have successfully implemented this kind of stuff before. I used to keep sections of the RFCs on speed dial. I've never had to deal with cloning app registrations.
Then, on each AAD tenant that wants to use this app, an admin for that tenant would create their instance of the app, called an enterprise application or service principal. That second object can choose whether any user in that tenant can sign in to the app or not, and can assign AAD roles to users/groups.
It is very common for apps to have a single tenant, and therefor the app registration and enterprise application are both in the same tenant, but if the app registration would allow it, any tenant can create their instance, and assign users from their tenant any role they desire.
This means that it is possible to have an app managed really well within your tenant, yet make the mistake of allowing sign-ins from other tenants, and thereby outsiders could still have full access...