📟Use of application permission

Application vs. Delegated Permissions for SharePoint, OneDrive, Outlook, Teams

To ensure a reliable SharePoint and OneDrive connection, amber uses Application permissions rather than Delegated permissions. This choice is fundamental for the SharePoint and OneDrive Connector to function as intended and follows Microsoft’s guidance for app development on when to use app-only access. In short, Microsoft recommends app-only access when an application must run without user involvement, touch data across many users, or avoid risky patterns like storing user credentials locally and impersonating users. These patterns include, for example, automated jobs that run on schedules and services that need to read content from many different users or channels.

Overview of Microsoft Graph permissions - Microsoft Graph | Microsoft Learn
Graphic from https://learn.microsoft.com/en-us/graph/permissions-overview?tabs=http

Why amber uses Application Permissions

  • Autonomous operation across the tenant
    amber runs continuously and independently of any specific user session. It must routinely crawl content, permission structures, and activity signals in SharePoint and OneDrive to keep the index accurate and fresh. This systematic operation requires a permission model that does not depend on a person being signed in.

  • Comprehensive, user-agnostic access
    Delegated permissions act “as a user,” inheriting that user’s limitations. By contrast, Application permissions allow amber to traverse all relevant areas—regardless of who is signed in—so content can be discovered, permissions respected, and updates captured consistently across the environment.

  • Efficiency and scalability at enterprise scale
    Large, distributed environments require asynchronous, wide-reaching data collection. Relying on Delegated permissions would tie crawling to individual user contexts and sessions, creating bottlenecks and operational gaps. Application permissions remove these constraints so amber can scale with your content and organizational complexity.

  • Tenant-wide rate limit resilience
    Microsoft Graph enforces tenant-level rate limits per registered application. If Delegated permissions were used, amber would need to perform distinct Graph API calls on behalf of each user for every request, quickly accelerating toward rate limits. Application permissions significantly reduce this overhead by eliminating per-user duplication, preserving throughput and overall platform stability.

Limitations of Delegated Permissions

  • Dependency on user context
    Delegated permissions restrict amber to what a currently signed-in user can access, which fragments coverage and may delay indexing. This dependency risks stale visibility of sensitive or newly restricted content because updates would only be captured when the relevant user is active again.

  • Interactivity assumptions
    Delegated permissions fit use cases where an app acts while a user interacts. amber’s crawl jobs, however, operate unattended and asset-by-asset. This non-interactive, background-first approach is inherently misaligned with Delegated permissions and their session-centric model.

Token Security and Authentication

amber’s crawlers authenticate to Microsoft Graph and SharePoint REST APIs using a Service Principal (App Registration). The Service Principal is configured with a client secret used for API requests. The security model is designed to protect this secret at rest, in transit, and during use.

Secure Storage

  • The client secret you provide to amber is stored in your tenant’s dedicated Secret Store, the same protected repository used for other connector credentials.

  • Each amber tenant has its own isolated Secret Store to prevent cross-tenant exposure.

  • Secrets are encrypted twice—once prior to being written and again at rest.

Secure Access

  • For each crawl, amber connectors use a designated service account to retrieve the client secret from the Secret Store.

  • The secret is held only in encrypted memory during the crawl and is discarded immediately afterward.

  • It is never persisted within the crawler, never embedded in code, and never written to disk in any amber component aside from the Secret Store.

Additional Controls

  • For heightened security, you can enforce IP restrictions via Entra ID Conditional Access, limiting usage of the client secret to the specific IP ranges associated with your amber tenant’s crawlers. This adds a network boundary on top of credential protections, further reducing risk.