1. Overview

1.1 Motivation

Microsoft Entra ID permissions are commonly rated using a static risk tier — Low, Medium, High, or Critical — based on generalized assumptions about individual scopes. While this offers a rough measure of permission sensitivity, it lacks transparency and fails to account for contextual risk. Critically, it evaluates permissions in isolation, without factoring in the application requesting them — its ownership, origin, credential hygiene, or operational footprint. As a result, two applications requesting the same scope may present vastly different risk profiles but are treated identically.

1.2 The dual-layer model

OARS addresses this gap through a dual-layer model that introduces structure, consistency, and governance-ready intelligence to consent decisions:

• Application-Level Risk Scoring evaluates the app’s inherent trust posture based on its source (internal or third-party), credential type, tenant breadth, redirect URI security, and governance signals such as ownership assignment, business necessity, and operational activity.
• Permission-Level Risk Scoring refines permission evaluation by breaking down scopes into discrete risk factors such as impersonation potential, data sensitivity, exfiltration capability, privilege escalation, and token persistence.

All scoring inputs are derived from authoritative and programmatically retrievable sources — Microsoft Entra ID via Microsoft Graph, curated permission registries, and usage telemetry. No manual attestation or self-reported values are used, ensuring every decision is grounded in verifiable signals.

Each factor is scored using fixed numeric values and grouped into clearly defined risk domains, allowing for transparent, additive scoring. Raw scores are normalized within their domain, weighted by the domain’s strategic security impact, and combined into a composite score on a 0–100 scale for each layer. The resulting Application Risk Tier and Permission Risk Tier are then evaluated together through a structured decision matrix that determines whether a consent request is auto-approved, routed to analyst review, or escalated for formal exception review.

This structured approach turns previously subjective judgments into repeatable, auditable, and automatable decisions, enabling consistent governance standards across both internal tools and third-party software, aligned with Zero Trust principles and least-privilege best practices. It also supports periodic re-evaluation to account for risk drift even when an application’s configuration has not changed, keeping consent governance current with evolving threat conditions.

1.3 Risk domain overview

To keep risk scoring transparent and modular, the framework separates application-level and permission-level domains. Application domains describe trust in the app itself; permission domains describe the impact of the scopes the app requests.

Scoring weights are applied through risk dimensions during aggregation. At the application level, domains group related factors while a separate set of dimensions carries the weights; at the permission level, domains and dimensions coincide, so each domain carries its weight directly.

Application-level risk domains

• App Trust & Exposure — How much inherent trust the app deserves based on its source, maturity, tenant breadth, impersonation capability, and redirect-URI hygiene.
• Authentication & Credential Hygiene — Strength of secrets or certificates, OAuth flow, managed-identity usage, and any privileged roles the app already holds.
• Compliance & Governance — Whether the app has assigned ownership, serves an active business purpose, and exercises the access it has been granted; drives operational accountability.

Application-level factors are weighted through three risk dimensions, independent of their domain grouping:

Risk Dimension	Weight
Application Profile & Exposure	25%
Permissions & Privilege Impact	50%
Governance & Lifecycle	25%

A factor’s domain describes what it measures; its dimension determines how heavily it counts. For example, App Maturity belongs to the App Trust & Exposure domain but is weighted under the Governance & Lifecycle dimension.

Permission-level risk domains

Risk Domain	Weight	What it captures
Identity & Privilege Escalation	40%	Scopes that let an app impersonate users, assign roles, or elevate privileges (for example RoleManagement.ReadWrite.All, user_impersonation).
Access Surface & Blast Radius	30%	How wide and deep a permission reaches once granted, combining scope type (delegated vs. app-only), reach (.All vs. user), operation class (read, write, delete), user count, and any ability to modify access policies.
Data Sensitivity & Leakage	25%	The value of the data (internal, confidential, PII) and the ease of exfiltration, flagging bulk-export or sync capabilities.
Compliance & Trust Heuristics	5%	Confidence-reducing indicators that signal audit gaps, such as reliance on deprecated or unsupported APIs (for example AAD Graph).

At the permission level, domains and dimensions coincide, so the weights above apply directly during aggregation.

---

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