11.3 OAuth App Policies & Catalog Management

OAuth apps: the consent attack surface

Not every cloud risk is a website users browse through a reverse proxy. Many threats arrive as “Sign in with Microsoft” buttons and OAuth consent prompts. A user (or an admin) grants a third-party application permissions to read mail, files, contacts, or calendar. The app then accesses data via Microsoft Graph or other APIs using tokens—often without continuous interactive browsing that session policies fully cover.

On SC-300, OAuth app governance sits at the intersection of:

• Microsoft Entra app registrations, enterprise applications, user consent, admin consent, and permission classification.
• Microsoft Defender for Cloud Apps OAuth app detection, investigation, and OAuth app policies.
• Cloud App Catalog risk context for the apps behind those OAuth clients.

/practice/azure-sc-300Practice questions with detailed explanations

OAuth app policies in Defender for Cloud Apps

OAuth app policies in MDCA focus on threat detection and governance for OAuth applications. At exam depth:

• They help you investigate which permissions each OAuth app requested.
• They support automated governance patterns such as marking apps authorized/unauthorized and revoking app authorization when risk thresholds match.
• Microsoft documents OAuth app policies as built-in style policy capabilities in the MDCA policy family (you work with the OAuth app governance experiences rather than inventing a brand-new protocol).

Exam cue phrases: “revoking OAuth permissions,” “unauthorized OAuth app,” “apps with high permission severity,” “users consenting to risky apps,” “OAuth app policy.”

Investigation workflow (conceptual)

1. Open OAuth apps inventory in Defender for Cloud Apps (product navigation evolves; concept is OAuth app governance).
2. Sort/filter by permission severity, community use, publisher, or app name.
3. Drill into an app: who consented, which permissions, last used.
4. Compare with business ownership—does a team claim this integration?
5. Revoke app authorization if unjustified or malicious; require re-consent under tighter Entra consent policy if still needed.
6. Document sanctioned OAuth integrations (enterprise apps with admin consent and least-privilege scopes).

Review and revoke risky OAuth grants

SC-300 expects you to act, not only list apps.

Where revocation and review happen

Response playbooks

Suspected malicious OAuth app

1. Revoke the app’s permissions / disable the enterprise application instance.
2. Revoke user sessions and refresh tokens for impacted users if compromise suspected.
3. Review sign-in logs and MDCA activity for data access patterns.
4. Reset credentials / require passwordless+phishing-resistant remediation as appropriate (Identity Protection chapter linkage).
5. Tighten user consent settings to prevent recurrence.

Legitimate but over-privileged app

1. Contact the app owner/vendor for least-privilege scopes.
2. Reconfigure app registration permissions; re-consent with reduced scopes.
3. Prefer application permissions only when a daemon truly needs them; otherwise delegated least privilege.
4. Assign owners on the enterprise app; tag as sanctioned in catalog processes.

Orphaned app after project ends

1. Confirm no production dependency.
2. Revoke OAuth grants; delete or disable enterprise app.
3. Remove related secrets/certificates from any app registration you own.
4. Update sanctioned app inventory.

Cloud App Catalog management

Section 11.1 introduced the catalog for discovery. Catalog management is the ongoing governance of how your organization treats those apps.

Scores and evaluation

• Use risk scores and security attributes when approving new SaaS.
• Prefer lower-risk alternatives when business function is equal.
• Revisit scores when a sanctioned app’s posture changes (vendor breaches, certification changes—process maturity, not daily busywork).

Organizational tagging / stance

Catalog hygiene tasks identity admins touch

• Ensure custom domains for customized/plugin apps map so discovery and CA App Control identify the right app.
• Avoid duplicate “unknown” apps when a catalog entry already exists—normalize naming in investigations.
• When onboarding CA App Control apps, catalog identity helps MDCA apply the correct heuristics.
• Feed catalog decisions into procurement and security architecture reviews.

Governance alongside Microsoft Entra consent

MDCA OAuth tools complement, they do not replace, Entra consent configuration. A complete SC-300 answer often stacks both.

Entra consent controls (recap for integration)

Integrated governance model

1. Prevent — tight Entra user consent defaults; admin consent workflow; verified publishers preferred.
2. Detect — MDCA OAuth inventory + policies; Entra permission grant audit logs.
3. Respond — revoke OAuth app; disable enterprise app; revoke sessions; investigate.
4. Recover / harden — least-privilege re-consent; owners; catalog sanctioned list; CA App Control for browser SaaS residual risk.
5. Review — periodic OAuth app reviews just like privileged role reviews (Domain 4 mindset).

End-to-end scenarios

Domain 3 MDCA wrap-up

Across this chapter you can:

1. Discover shadow IT and evaluate apps with the Cloud App Catalog (11.1).
2. Connect sanctioned apps via API connectors for depth (11.1).
3. Control browser sessions with Conditional Access App Control and MDCA access/session policies, and distinguish app-enforced restrictions (11.2).
4. Govern OAuth apps, revoke risky grants, and manage catalog stance alongside Entra consent (11.3).

/study-guides/azure-sc-300Free exam prep with practice questions & AI tutor