2.1.5. OAuth Permission Grants and Consent Settings
💡 First Principle: An application requesting a permission and an application having that permission are two different states separated by one deliberate act — consent — and controlling who can grant that consent is one of the highest-leverage governance decisions in the tenant.
Delegated permissions let an application act as the signed-in user, limited to what that user could do themselves. Application permissions let it act as itself, independent of any signed-in user — these are more powerful and always require administrator consent, never user consent. Consent settings determine whether individual users can consent to delegated permissions on their own behalf, whether admin consent is required tenant-wide, and whether an admin consent workflow routes risky requests for review instead of an outright block.
⚠️ Exam Trap: Restricting user consent doesn't disable OAuth application access entirely — it shifts the approval decision to administrators (ideally through an admin consent workflow) rather than leaving individual users able to grant applications access to organizational data. A scenario asking "how do you stop users from unknowingly granting a malicious app data access" is testing this consent-restriction mechanic, not app registration deletion.
Reflection Question: Why would an organization want an admin consent workflow rather than simply disabling user consent outright with no alternative path?
