4.3. App Registrations

💡 First Principle: Registering an app is writing its identity contract: who may sign in (audience), where tokens may be delivered (redirect URIs), how the app proves itself (credentials), and what it may ask to do (permissions and roles). Every field is an attack-surface decision — the registration blade is a security document wearing a form's clothing.

Care because your organization's own software inherits exactly the risks this phase has been managing in vendors: over-broad audiences invite foreign sign-ins, sloppy redirect URIs enable token interception, eternal client secrets end up in repos. The exam tests the contract fields and, heavily, the permission model — 4.3.2's delegated-vs-application distinction may be the single most-tested concept in this domain.

⚠️ Common Misconception: Multitenant is the future-proof default. Single tenant is the correct default; multitenant means any Entra tenant's users can attempt sign-in and consent, expanding both attack surface and support scope. Go multitenant only when the app is genuinely a product for other organizations.