Oauth2PermissionGrant

An oauth2PermissionGrant is the directory object that records delegated permissions that are actually live. It is the authoritative entitlement record for a client, resource, and principal combination, and it can be narrower than the registration’s requested scope list.

Expanded Definition

An oauth2PermissionGrant is the directory object that records delegated access that is actually active, not merely requested. In Microsoft Entra style consent models, it ties together the client, the resource API, and the consenting principal, which is why it functions as the authoritative entitlement record for delegated OAuth use.

That distinction matters because application registration scopes, admin consent prompts, and runtime grants can diverge. A registration may request broad permissions, but the live grant can be narrower, conditional on who consented and what was approved. In NHI governance, the object therefore belongs to entitlement review, not just app inventory. The OWASP Non-Human Identity Top 10 treats overly broad delegated access as a recurring risk pattern, while NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces the need to control access permissions and review them continuously.

Definitions vary across vendors when discussing whether consent records, service principal grants, and application permissions should be grouped together, so teams should be precise about the object being inspected. The most common misapplication is treating the app registration as proof of live delegated access, which occurs when administrators review requested scopes instead of querying the actual grant object.

Examples and Use Cases

Implementing oauth2PermissionGrant review rigorously often introduces operational friction, because security teams need to balance fast user consent with tighter control over standing delegated access.

• A SaaS connector is approved for calendar read access, but the live grant only covers a subset of scopes, so the directory object becomes the source of truth during audit.
• An admin consented AI assistant can inherit delegated access to mail and files, which makes the grant object crucial when investigating activity similar to the Salesloft OAuth token breach.
• Security operations teams use grant reviews to identify shadow integrations, especially after incidents involving third-party OAuth visibility gaps described in the State of Non-Human Identity Security.
• Offboarding workflows revoke stale delegated access by removing the grant object, which is faster and more reliable than only disabling the app registration.
• Investigators compare scope requests against actual grants when assessing whether a breach followed over-consent or post-consent escalation, as seen in cases like the Klue OAuth Supply Chain Breach.

For implementation context, directory administrators often align this work with consent governance guidance in the Ultimate Guide to NHIs and with delegated permission review patterns in NIST control families.

Why It Matters in NHI Security

oauth2PermissionGrant is important because delegated access is often where NHI risk becomes invisible. An organisation can believe an application is tightly scoped while the live grant still authorises access to high-value data. This is especially dangerous in environments with many third-party OAuth apps, where NHIMG research shows 85% of organisations lack full visibility into vendor connections through OAuth, and 47% have only partial visibility.

That visibility gap turns consent records into a governance blind spot. If the grant object is not monitored, revoked on offboarding, and periodically revalidated, attackers can persist through authorized-looking access even after a credential reset or app review. This is why the State of Non-Human Identity Security and the broader Ultimate Guide to NHIs both emphasise visibility, rotation, and revocation discipline across the NHI lifecycle. In practice, teams use grant inventories to detect over-privileged delegated access before it becomes a breach path.

Organisations typically encounter oauth2PermissionGrant as an urgent issue only after a compromised integration, suspicious mailbox access, or a third-party OAuth incident makes delegated permissions operationally unavoidable to address.