2. Application-Level Risk Factors

2.1 Purpose

Application-level risk factors evaluate an OAuth application’s inherent trustworthiness, technical posture, and governance maturity independent of the specific permissions it requests. Rather than asking “what can this app do?”, this layer focuses on “who built the app, how is it configured, and how is it managed?”

Each factor captures a discrete dimension of application risk, such as:

• Origin and exposure — internal vs. external publisher, single-tenant vs. multi-tenant reach
• Configuration hygiene — redirect URI setup, user assignment, guest access
• Credential posture — managed identity, certificates, or client secrets; OAuth client type and flow
• Governance maturity — ownership accountability, active usage, and business necessity

Each factor is assigned a raw score (typically 0–3) and contributes to the final score through one of the three weighted risk dimensions described in §1.3: Application Profile & Exposure, Permissions & Privilege Impact, and Governance & Lifecycle. Within each dimension, raw scores are normalized on a 0–100 scale, then weighted and aggregated into a final application risk score (0–100), which maps to one of four risk tiers: Low, Medium, High, or Critical.

This structured approach ensures that all signals are considered while emphasizing what matters most. A single high-severity trait (for example a wildcard redirect, missing ownership, or a public client with secrets) can independently elevate an app’s classification, while compounding moderate concerns (open user assignment, stale credentials, no active usage) across dimensions can collectively raise the tier even when no single trait scores highly. Conversely, internal apps with clear ownership, secure credential configuration, and limited exposure typically remain in the Low tier.

The result is a transparent, explainable, and scalable evaluation model in which the application’s own posture — not just the permissions it requests — shapes the consent decision.

2.2 Domain: App Trust & Exposure

How much inherent trust the app deserves based on its source, maturity, tenant breadth, impersonation capability, and redirect-URI hygiene.

Risk Factor	Overview and Risk Impact	Risk Scoring	Risk Dimension
Application Source	Indicates who created the app: internal (trusted), external verified (moderate trust), or external unverified (high risk). Helps assess app trustworthiness and potential for abuse.	Internal / approved tenant: 0 External – verified: 2 External – unverified: 3	Application Profile & Exposure
Tenant Breadth	Determines whether the app is single-tenant (low exposure) or multi-tenant (broad access). Multi-tenant apps increase exposure to external misuse.	Single-tenant: 0 Multi-tenant: 2	Application Profile & Exposure
Combo Permissions	Measures the risk amplification when two or more permissions are combined in a way that increases abuse potential (for example offline_access + Files.ReadWrite.All). These combinations allow persistent, high-impact access and can bypass typical control boundaries.	Not triggered by default One known risky pairing present: +2 Multiple risky combinations or sensitive escalation patterns: +3–5	Permissions & Privilege Impact
App Maturity	Shows how long the app has been in the tenant. New apps may be malicious or unvetted, while older apps may have governance history.	> 12 months: 0 3–12 months: 1 < 30 days: 2 < 7 days: 3	Governance & Lifecycle
Redirect URI Method	Refers to how an app receives tokens (loopback, mobile URI, web URI). Impacts token security and exposure.	Microsoft URI: 0 Loopback / mobile URI: 0 Static HTTPS web URI: 1 Custom / wildcard URI: 2–3	Application Profile & Exposure
Redirect URI Ownership	Checks who owns the domain receiving tokens. Untrusted or wildcard domains increase risk of token hijacking.	Verified HTTPS: 0 Third-party verified: 1 HTTP / wildcard / unverified: 2–3	Application Profile & Exposure
User Assignment Enforcement	Indicates whether users or groups are explicitly assigned to the app. Lack of assignment control can result in broad unintended access.	Assignment required: 0 Open to all users: 2 Open + guest allowed: 3	Permissions & Privilege Impact
Guest Access	Shows whether B2B or federated users can access the app. Increases external exposure and weakens control.	Guests blocked: 0 Limited guest access: 1 Guests allowed broadly: 2–3	Governance & Lifecycle
Publisher Verification	Verified publishers are Microsoft-trusted; unverified may be fraudulent. Adds assurance about authenticity for third-party apps.	Verified: 0 Unverified: 2	Application Profile & Exposure
M365 Certification	Apps with M365 certification meet Microsoft security and compliance standards, reducing vetting burden.	Certified: 0 Not certified: 1	Governance & Lifecycle

2.3 Domain: Authentication & Credential Hygiene

Strength of secrets or certificates, OAuth flow, managed-identity usage, and any privileged roles the app already holds.

Risk Factor	Overview and Risk Impact	Risk Scoring	Risk Dimension
OAuth Client Class	Distinguishes whether the app can store secrets (confidential) or not (public). Public apps pose greater exposure risk.	Confidential with certificate: 0 Confidential with secret: 1–2 Public client: 2–3	Permissions & Privilege Impact
OAuth Flow Security	Evaluates OAuth grant type security. Some flows (ROPC, implicit) are deprecated or insecure.	Auth code + PKCE: 0 OBO / device code: 1 Client credentials: 2 ROPC / implicit: 3	Permissions & Privilege Impact
Managed Identity Adoption	Apps using managed identity are more secure (no secrets, auto-rotated). Managed identity avoids credential leakage and rotation risk.	Uses only managed identity: 0 Certificate only: 1 Client secret or mixed: 2	Application Profile & Exposure
Credential Strength	Describes how the app authenticates: secret, certificate, or managed identity. Secrets are vulnerable unless rotated and stored securely.	Managed identity or certificate: 0 Secret (rotated): 1 Secret (static or expired): 2–3	Permissions & Privilege Impact

2.4 Domain: Compliance & Governance

Whether the app has assigned ownership, serves an active business purpose, and exercises the access it has been granted.

Risk Factor	Overview and Risk Impact	Risk Scoring	Risk Dimension
Ownership Assignment	Apps with multiple owners are easier to govern. Orphaned apps increase lifecycle and accountability risks.	≥ 2 full-time employee owners: 0 High-tier or above with no active owners: 2 Guest-only or no owners: 3	Governance & Lifecycle
Over-Privileged Access	Flags apps that have been granted permissions they do not use. Unused high-privilege scopes increase attack surface and violate least privilege.	Measured within 90 days — ≥ 90% of permissions used: 0 50–90% used: 1 < 50% used: 2 None used, or unused high-privilege scopes: 3	Permissions & Privilege Impact
Business Necessity	Assesses whether the app serves an active business purpose. Obsolete, redundant, or unused apps unnecessarily expand the attack surface even if they are secure.	Core platform or enterprise-critical app: 0 Business-critical LOB app with regular use: 1 Low usage, or duplicates an existing app: 2 Dormant, no usage, or labelled obsolete/test: 3	Governance & Lifecycle
App Activity	Evaluates whether the app is actively used. Unused apps may indicate stale configurations, governance gaps, or abandoned access.	Active in last 30 days: 0 Used within 31–90 days: 1 Used within 91–180 days: 2 No usage in past 180 days or ever: 3	Governance & Lifecycle

---

OARS §2 is derived from the Graph Consent Risk Framework by Khurram Chaudhary. Licensed CC BY 4.0.