Our company does not allow sites.readwrite.all in Azure, instead allowing sites.selected, and n8n is returning 403 forbidden

Questions
1

Describe the problem/error/question

Our company does not allow the permission SITES.READWRITE.ALL in Azure, instead using sites.selected. Every GET request we make from n8n, returns 403 forbidden. The AI Chatbot in N8N says that there’s no documentation granting that n8n can work with sites.selected. Is there any case of functioning instance with this permission?

What is the error message (if any)?

Please share your workflow

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)

Share the output returned by the last

403 FORBIDDEN

Information on your n8n setup

  • n8n version: 2.16.1
  • Database (default: SQLite): n8n + PostgreSQL 16 + Nginx (Docker Compose)
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app): docker
  • Operating system: Ubuntu 24.04 LTS
3

I would split this into a permission proof and a node-choice proof before changing the workflow itself.

For Sites.Selected, the smallest useful test matrix would be:

  1. Confirm the token type you are using in n8n: delegated user token (scp) versus application/client-credentials token (roles).
  2. Confirm the exact SharePoint site grant for that app: site id/url, app id, and granted role, using redacted names only.
  3. Test three Microsoft Graph calls outside the native SharePoint node with the same app: GET /sites/{site-id}, GET /sites/{site-id}/drive/root, and GET /sites/{site-id}/lists.
  4. Repeat those same calls in n8n with an HTTP Request node, using fixed site/list ids rather than dropdown discovery.
  5. If the Graph probes return 200 but the native SharePoint node still returns 403 or cannot populate dropdowns, keep the first version on HTTP Request + Graph endpoints and document the native-node limitation instead of widening the tenant permission to Sites.ReadWrite.All.

The key distinction is whether the 403 is coming from a missing per-site grant, the wrong token type, dropdown/list-discovery behavior in the native node, or an endpoint that still expects broader tenant/site permissions.

For a clean handoff, I would keep a small table with: endpoint, token type, granted site, expected role, response code, and next action. No tenant secrets, app secrets, certificates, private file names, or production documents need to be shared publicly for that.

4

Welcome @Alb_Va to our community! I’m Jay and I am a n8n verified creator.

One critical step that’s often missed with Sites.Selected: granting the permission in Azure Portal alone is not enough. Your IT Admin also needs to explicitly grant the app access to the specific SharePoint site using Microsoft Graph API or PowerShell - setting the permission in the App Registration just enables the permission type, but the actual site-level grant is a separate step.

The PowerShell command to add the site grant:

$siteId = "your-site-id"
$appId = "your-app-id"
Invoke-MgGraphRequest -Method POST -Uri "https://graph.microsoft.com/v1.0/sites/$siteId/permissions" -Body @{
  roles = @("write")
  grantedToIdentities = @(@{application = @{id = $appId; displayName = "n8n"}})
} | ConvertTo-Json

Without this step, every call returns 403 regardless of token type. Once the site grant is in place, the HTTP Request node approach @smalltoolslab described should work.

5

welcome to the community @Alb_Va
have you already asked the azure admin to enable n8n or are you trying to automate processes without IT’s knowledge huh? :laughing:

6

Good morning! We’ve been managing this with them from the start. N8N support indicates that there are other permissions that N8N should have, which are:

Sites.ReadWrite.all

SearchConfiguration.Read.All,

SearchConfiguration.ReadWrite.All

Directory.Read.All

We replaced sites.readwrite.all with sites.selected, also specifying the site through graph and granting admin consent. Then, they also allowed us SearchConfiguration.Read.All, but the SharePoint node continues to give us a 403 forbidden error. What we have managed to achieve after receiving SearchConfiguration.Read.All is to make an HTTP request to our site and receive the list of folders and items. It’s progress, but only from an HTTP request node, since the SharePoint node still doesn’t work.

7

Good morning Jay, explicit access was indeed granted, but instead of the PowerShell command, a POST was launched in graph:

POST https://graph.microsoft.com/v1.0/sites/site_id/permissions

{

“roles”: [“write”],

“grantedToIdentities”: [{“application”: {“id”: “app_id”,“displayName”: “app_name”}}]

}

We understand that the function is the same and that the permission was granted correctly

8

@Alb_Va

Are the nodes calling exactly the same endpoints internally? If they’re taking different paths, the 403 could be coming from auxiliary calls and not from permission on the site. If you can share the exact endpoint that works in the HTTP Request; the exact operation used in the SharePoint node; and the complete error/output from the SharePoint node, it will be easier for me to understand and help.

9

The n8n SharePoint node makes a few auxiliary calls beyond just the main operation - it resolves the site drive, checks permissions context, etc. - and those auxiliary calls may be hitting endpoints not covered by your sites/{site_id}/permissions grant. The cleanest fix here is to replicate the exact Graph API calls from the HTTP Request node that already works, and skip the SharePoint node entirely. You already have the working pattern - just build around HTTP Request and you avoid the node’s internal routing logic altogether.