SharePoint App-Only Authentication: Entra ID Setup and Agent Storage Access

Microsoft retired Azure Access Control Service (ACS) for SharePoint Online on April 2, 2026, permanently terminating the legacy AppRegNew.aspx and AppInv.aspx authentication workflows that scripts and background daemons relied on for over a decade.

SharePoint App-Only authentication is an unattended machine identity protocol that allows background daemons, scripts, and AI agents to access SharePoint Online without user interaction using Entra ID app credentials or certificates. For organizations maintaining core document libraries in SharePoint Online, autonomous software requires programmatic access to files without relying on interactive user sessions, browser logins, or manual sign-in prompts.

Most online tutorials still recommend deprecated ACS appregnew.aspx/appinv.aspx methods that fail on modern SharePoint Online tenants. Historically, developers navigated to hidden SharePoint pages like _layouts/15/AppRegNew.aspx to generate a client ID and client secret, then pasted XML permission requests into _layouts/15/AppInv.aspx. When calling the legacy accounts.accesscontrol.windows.net token broker, that architecture bypassed enterprise identity governance. On modern SharePoint Online tenants, requests directed to legacy ACS endpoints fail with HTTP 401 Unauthorized or HTTP 403 Forbidden errors.

The Decommissioning of Azure Access Control Service

The deprecation of Azure ACS began when Microsoft introduced modern application registrations in Microsoft Entra ID (formerly Azure Active Directory). Legacy ACS tokens lacked centralized credential rotation, granular access policies, and unified audit logging. When Microsoft completed the retirement on April 2, 2026, the underlying token issuance service was disabled entirely.

Modern unattended integration requires shifting authentication to Microsoft Entra ID application registrations. In this modern model, an identity administrator defines an application registration within the tenant, provisions cryptographic credentials, requests specific API application permissions, and records tenant administrator consent.

Service Principals Versus Interactive Delegated Identities

Application authentication differs from delegated user authentication in how permissions are evaluated:

• Delegated permissions act on behalf of a signed-in human user. The application can access only what the interactive user has permission to view, and every session requires interactive consent or refresh tokens. When an unattended daemon or automated agent runs on a remote server, delegated flows fail whenever refresh tokens expire or conditional access policies interrupt the session.
• Application permissions (app-only) act as the application's own service principal identity. The daemon or autonomous agent authenticates directly against Microsoft Entra ID without human presence. The application receives a JSON Web Token (JWT) bearing role claims assigned directly to its service principal.

Unattended app-only access to SharePoint Online APIs via Microsoft Entra ID requires authenticating with a certificate rather than a client secret. While standard Entra ID applications calling Microsoft Graph can technically use symmetric client secrets, SharePoint Online explicitly blocks symmetric client secrets for app-only calls to SharePoint Client Side Object Model (CSOM) and SharePoint REST endpoints. To authenticate unattended processes against SharePoint storage, engineering teams must configure asymmetric X.509 certificate credentials.

• Connecting AutoGen Multi-Agent Systems to SharePoint: Architecture and SetupAn AutoGen SharePoint connector enables Microsoft AutoGen agent teams to authenticate against Microsoft Graph and query...
• Amazon Bedrock SharePoint Connector: Setup, Limitations, and AlternativesThe Amazon Bedrock SharePoint connector allows Amazon Bedrock Knowledge Bases to ingest and index documents stored in...
• ChatGPT SharePoint Connector: Enterprise Setup vs. Fast.io MCP WorkspacesConnecting ChatGPT to SharePoint document libraries gives conversational models access to enterprise knowledge. While...
• SharePoint Agent: Connecting Autonomous AI Agents to SharePoint StorageConnecting autonomous AI agents to enterprise SharePoint storage gives tool-calling assistants access to company...
• How to Connect ChatGPT to SharePoint Document LibrariesConnecting ChatGPT to SharePoint allows conversational AI models to query enterprise document libraries through...
• How to Connect Dify AI to Microsoft SharePointConnecting Dify to SharePoint enables agentic workflows and LLM applications to retrieve, cite, and analyze enterprise...

More on this subject: Agent File and Document Workflows (298 guides)

Establishing modern SharePoint app-only authentication requires a structured four-step procedure: Entra ID app registration, certificate upload, API scope assignment, and admin consent. Each step establishes the cryptographic trust and authorization boundary necessary for unattended daemons and AI storage connectors.

Step 1: Register the Application in Microsoft Entra ID

Navigate to the Microsoft Entra admin center (https://entra.microsoft.com) and open Identity > Applications > App registrations. Select New registration to create the machine identity:

1. Enter a descriptive display name, such as SharePoint-Storage-Daemon.
2. Under supported account types, select Accounts in this organizational directory only (Single tenant) to restrict authentication to your organization.
3. Leave the redirect URI empty, or select Public client/native (mobile & desktop) with http://localhost if using local developer tooling.
4. Select Register to instantiate the application. Record the Application (client) ID and Directory (tenant) ID from the overview panel.

Step 2: Generate and Upload an X.509 Certificate

SharePoint Online enforces asymmetric key cryptography for unattended app-only tokens. The calling application signs an authentication assertion using a private key, and Entra ID verifies the signature using the corresponding public certificate.

You can generate a self-signed certificate using PowerShell or OpenSSL. In PowerShell on Windows or macOS:

$cert = New-SelfSignedCertificate -Subject "CN=SharePointStorageConnector" `
    -CertStoreLocation "Cert:\CurrentUser\My" `
    -KeyExportPolicy Exportable `
    -KeySpec Signature `
    -KeyLength 2048 `
    -KeyAlgorithm RSA `
    -HashAlgorithm SHA256

Export-Certificate -Cert $cert -FilePath "./SharePointStorageConnector.cer"

To use the certificate in a headless script or containerized agent, export the private key as an encrypted PFX or PEM file:

$password = ConvertTo-SecureString -String "YourSecurePassphrase" -Force -AsPlainText
Export-PfxCertificate -Cert $cert -FilePath "./SharePointStorageConnector.pfx" -Password $password

In the Entra admin center, select your app registration and navigate to Certificates & secrets > Certificates. Select Upload certificate, select the public .cer file, provide a description, and save. Note the certificate Thumbprint, which identifies the key during token requests.

Step 3: Assign API Scopes

Navigate to API permissions > Add a permission. You must determine whether your integration calls Microsoft Graph or the legacy SharePoint CSOM/REST endpoints:

• Microsoft Graph (Recommended): Select Microsoft Graph > Application permissions. Search for Sites.Selected (for site-scoped least privilege) or Sites.Read.All (for tenant-wide read access).
• SharePoint API: Select APIs my organization uses, search for Office 365 SharePoint Online, and select Application permissions. Choose Sites.Selected or Sites.Read.All.

Step 4: Grant Tenant Administrator Consent

Application permissions do not function until an authorized administrator grants consent. In the API permissions screen, select Grant admin consent for your directory. Confirm the dialog. The status column updates to show a green checkmark indicating active consent across the tenant directory.

The OAuth 2.0 Client Assertion Flow

When an automated script or agent requests an access token, it does not send a raw password over the wire. Instead, it constructs a signed JWT client assertion:

1. The client constructs a JSON payload containing the client ID, tenant token endpoint URL, a unique token identifier (JTI), and an expiration timestamp.
2. The JWT header specifies the RSA algorithm (RS256) and the base64-encoded SHA-1 thumbprint of the certificate (x5t).
3. The client signs the header and payload using its private RSA key.
4. The client issues an HTTP POST request to https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token:

POST /your-tenant-id/oauth2/v2.0/token HTTP/1.1
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=00000000-0000-0000-0000-000000000000
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6...
&scope=https://graph.microsoft.com/.default

Entra ID validates the signature against the registered public certificate and returns a short-lived access token valid for sixty minutes.

Application-only permissions operate tenant-wide unless explicitly restricted via Sites.Selected. Understanding this architectural constraint is critical for security teams provisioning storage access for automated systems.

The Blast Radius of Tenant-Wide Application Permissions

When an administrator assigns standard application permissions like Sites.Read.All or Sites.FullControl.All, the permission applies to every site collection, document library, subsite, and file across the entire Microsoft 365 tenant. The service principal can read confidential financial disclosures, executive communications, human resources files, and unreleased intellectual property.

In traditional human workflows, user access is bounded by group membership and departmental permissions. When an unattended daemon or autonomous AI agent holds a tenant-wide token, any flaw in the agent's logic or prompt injection in an LLM reasoning loop could expose documents from outside the intended project. A script designed to extract invoice totals from an accounts payable site must not hold the ability to read legal dispute filings from an executive team site.

Implementing Sites.Selected via Microsoft Graph

The Sites.Selected permission scope solves this exposure by decoupling application registration from site-level access grants. When an application holds Sites.Selected, it possesses zero inherent access to any SharePoint site collection. An administrator or site collection manager must explicitly grant the application access to specific target sites.

To assign granular site access after granting Sites.Selected admin consent:

1. Identify the target site's unique identifier by issuing a GET request:

GET https://graph.microsoft.com/v1.0/sites/{tenant-domain}.sharepoint.com:/sites/{site-name}?$select=id
Authorization: Bearer <admin-access-token>

2. Post a permission grant linking your application ID to the site collection:

POST https://graph.microsoft.com/v1.0/sites/{site-id}/permissions
Authorization: Bearer <admin-access-token>
Content-Type: application/json

{
  "roles": ["read"],
  "grantedToIdentities": [
    {
      "application": {
        "id": "00000000-0000-0000-0000-000000000000",
        "displayName": "SharePoint-Storage-Daemon"
      }
    }
  ]
}

The roles array accepts values such as read, write, or readwrite. Once this permission record is created, the application can read documents within that specific site collection. If the application attempts to query any other site or list files from an unassigned library, Microsoft Graph returns an HTTP 403 Forbidden status code. Engineering teams can audit, grant, and revoke access on a site-by-site basis without modifying the core Entra ID application registration.

Establishing an authenticated connection via Entra ID solves machine identity, but pointing autonomous AI agents directly at SharePoint Online via Microsoft Graph API introduces severe runtime friction. Enterprise document repositories were architected for human navigation through browser portals, not for high-concurrency passage retrieval by language models.

Rate Limits, HTTP 429 Throttling, and Traversal Latency

SharePoint Online enforces dynamic request limits to protect multi-tenant infrastructure from resource exhaustion. Throttling is evaluated across applications, users, and overall tenant capacity. When an AI agent performs deep research across document collections, it must recursively traverse nested folder structures:

GET https://graph.microsoft.com/v1.0/sites/{site-id}/drive/root/children
GET https://graph.microsoft.com/v1.0/sites/{site-id}/drive/items/{folder-id}/children
GET https://graph.microsoft.com/v1.0/sites/{site-id}/drive/items/{file-id}/content

Walking deep folder trees requires dozens of sequential API calls. As the frequency of requests increases, Microsoft Graph returns HTTP 429 Too Many Requests status codes accompanied by a Retry-After header. These rate limits frequently require the caller to pause execution for several seconds or minutes.

In autonomous agent frameworks like Claude Code, CrewAI, or LangGraph, multi-minute execution pauses cause tool call timeouts. The agent loop breaks, reasoning chains collapse, and automated pipelines halt before completing their document analysis tasks.

Context Dilution and Unindexed File Ingestion

Microsoft Graph serves whole file binaries, not semantically indexed text chunks. To answer a focused operational question, such as verifying an indemnification clause in a supplier agreement, an agent querying Graph directly must download an entire forty-page document.

Downloading raw files forces the agent runtime to parse file formats in memory and inject tens of thousands of tokens of boilerplate into the model's prompt window. This ingestion pattern produces three major failures:

• Token budget exhaustion: Context windows fill rapidly, leaving little room for multi-step reasoning or complex instructions.
• Context dilution: Language models lose accuracy when searching for specific details buried inside massive, unindexed prompt contexts.
• Scanned document blindness: SharePoint document libraries contain image-based PDFs, scanned contracts, and presentation decks that lack embedded text layers. Without a separate OCR pipeline, Graph returns raw binary data that the agent cannot interpret.

Decoupling Storage Synchronization from Agent Retrieval

The architectural solution separates long-term storage governance from agent retrieval. The enterprise maintains SharePoint as its primary system of record for corporate compliance and human collaboration, while synchronizing target libraries into an intelligent Fastio workspace.

Folder synchronization runs one-way or two-way, on a schedule or on demand. Google Drive folders sync like Dropbox, Box, and OneDrive; operations run on demand rather than in real time. SharePoint libraries are reached through the OneDrive connector without requiring tenant-wide global administrator consent.

Fastio publishes a head to head comparison of agent file work across Fastio and the major cloud storage providers at Fastio Benchmarks. Fastio was measured the fastest and the lowest cost of the providers tested.

Incoming files are automatically parsed, chunked, and indexed in the cloud. Instead of issuing dozens of Graph calls to traverse folder trees, AI agents connect through a remote Model Context Protocol (MCP) server, searching indexed content directly.

Creating an account is free; doing real work requires an organization on a paid subscription. Monthly plans start with a 14-day free trial that requires a credit card. Plans are Starter at $9.99/mo, Business at $49.99/mo, and Enterprise at $199.99/mo on Fastio pricing.

Ground Autonomous Agents in SharePoint Documents

Sync SharePoint document libraries into an intelligent workspace with hybrid semantic search and a remote MCP server for your AI agents. Starts with a 14-day free trial, credit card required.

Start 14-Day Trial

Decoupling storage from retrieval allows autonomous agents to interact with corporate documentation using specialized tool interfaces rather than raw HTTP file downloads. Fastio provides a remote Model Context Protocol endpoint that exposes workspace search, structured metadata extraction, and persistent file storage to language models.

Headless Agent Configuration and Streamable HTTP Transport

The Fastio MCP server is remote, hosted over Streamable HTTP with dedicated endpoints tailored to each client category:

• https://mcp.fast.io/mcp/tools for Claude applications, OpenClaw, and general personal-agent runtimes.
• https://mcp.fast.io/mcp/operations for custom ChatGPT and Codex connectors.
• https://mcp.fast.io/mcp/code for coding assistants, including Claude Code, Cursor, Cline, and VS Code.

For unattended daemons, scheduled cron jobs, and headless agent pipelines operating without a browser, authentication is handled by passing a scoped API key as an Authorization: Bearer <api key> header on the Streamable HTTP connection.

When configuring Claude Code via command line:

claude mcp add --transport http fast-io https://mcp.fast.io/mcp/code

In automated workflows using Python or framework agents, pass the bearer credential directly in client configuration headers. Once connected, the model accesses a consolidated MCP toolset without requiring local sync daemons, filesystem bridges, or complex Graph pagination routines.

Hybrid Semantic Search and Structured Metadata Extraction

Instead of streaming multi-megabyte binary documents across the network, agents query Fastio using hybrid search. The search engine combines sparse lexical indexing for exact part numbers, contract codes, and entity names with dense vector embeddings that capture semantic intent.

When an agent issues a query, Fastio returns ranked document excerpts accompanied by source file identifiers and exact page numbers. The agent receives precise context in a single tool interaction, consuming hundreds of tokens rather than tens of thousands of tokens of raw document text.

For structured document workflows, Fastio provides Metadata Views. Metadata Views turn unstructured document libraries into queryable tables. Users and agents define fields in natural language, and the system populates a schema across seven supported data types: Text, Integer, Decimal, Boolean, URL, JSON, and Date & Time. Values are extracted from scanned PDFs, images, spreadsheets, and handwritten notes without manual OCR templates. Agents query extracted metadata directly through MCP, filtering files by field values before reading document passages.

Multi-Agent File Persistence and Advisory Locks

When multiple autonomous agents collaborate within a synced workspace, concurrent operations require clear coordination:

• Version History: Every file maintains comprehensive version history. Concurrent writes from different agents create distinct versions, allowing teams to inspect diffs and roll back modifications without data loss.
• Advisory File Locks: Agents coordinate write operations using advisory file locks. An agent acquires a lease via lock-acquire on the storage_manage tool and releases it with lock-release. Other agents inspect lock-status on the storage tool to identify the active leaseholder. Locks expire automatically unless refreshed, preventing deadlocks if an agent process terminates unexpectedly.
• Workspace Activity Feed: Daemons monitor workspace changes using a long-polling endpoint (GET /current/activity/poll/{entity_id}) or a WebSocket subscription. When updated SharePoint documents sync into the workspace, background agents detect the modification and trigger downstream analysis pipelines immediately.