feat(credentials): expand Microsoft SharePoint OAuth2 default scopes

[F4brizio]

Summary

Expand the default OAuth2 scopes in MicrosoftSharePointOAuth2Api credentials to include additional Microsoft Graph/SharePoint permissions:

• Sites.Read.All
• Sites.ReadWrite.All
• Files.Read.All
• Files.ReadWrite.All

This ensures broader access to SharePoint sites and files when authenticating.

How to test

1. Create or update credentials using Microsoft SharePoint OAuth2 API.
2. Authenticate via OAuth2 flow.
3. Verify that workflows can successfully read and write to files and sites across SharePoint.

---

Related Linear tickets, GitHub issues, and Community forum posts

---

Review / Merge checklist

• PR title and summary follow conventions.
• Docs updated or follow-up ticket created.
• Tests included (if applicable).
• PR labeled with release/backport if urgent fix.

[CLAassistant]

All committers have signed the CLA.

[Joffcom]

Hey @F4brizio,

Thank you for your contribution. We appreciate the time and effort you’ve taken to submit this pull request.

Before we can proceed, please ensure the following:
• Tests are included for any new functionality, logic changes or bug fixes.
• The PR aligns with our contribution guidelines.

Regarding new nodes:
We no longer accept new nodes directly into the core codebase. Instead, we encourage contributors to follow our Community Node Submission Guide to publish nodes independently.

If your node integrates with an AI service that you own or represent, please email nodes@n8n.io and we will be happy to discuss the best approach.

About review timelines:
This PR has been added to our internal tracker as "GHC-4130". While we plan to review it, we are currently unable to provide an exact timeframe. Our goal is to begin reviews within a month, but this may change depending on team priorities. We will reach out when the review begins.

Thank you again for contributing to n8n.

[cubic-dev-ai]

1 issue found across 1 file

_{React with 👍 or 👎 to teach cubic. You can also tag @cubic-dev-ai to give feedback, ask questions, or re-run the review.}

[Joffcom]

Hey @F4brizio

These scopes shouldn't be needed if they are set on the Azure app side.

Can you provide more information on why these are needed?

[F4brizio]

Oye@F4brizio

Estos ámbitos no deberían ser necesarios si están configurados en el lado de la aplicación de Azure.

¿Puede proporcionarnos más información sobre por qué son necesarios?

Hi @Joffcom

I proposed this change because the current MicrosoftSharePointOAuth2Api credential in n8n was always issuing access tokens with only openid offline_access profile. This meant that, even if the Azure AD app had already been granted Sites.* and Files.* permissions on the Azure side, those permissions never appeared in the token. As a result, any workflow trying to call Microsoft Graph endpoints like /sites or /drives would consistently fail with 403 Forbidden – insufficient privileges.

By expanding the default scopes to include:

• Sites.Read.All
• Sites.ReadWrite.All
• Files.Read.All
• Files.ReadWrite.All

the credential now explicitly requests the permissions that SharePoint and Graph actually require for file and site operations. This ensures that the access token contains the necessary claims and allows workflows to successfully read and write to sites and files.

In short, this PR solves the 403 errors users encounter when trying to interact with SharePoint files and sites via the built-in credential, without forcing them to switch to a generic OAuth2 setup just to get the right scopes.

I am facing the same problem described in issue #18273, and this PR is my suggestion to solve it.

[Joffcom]

Hey @F4brizio

That is interesting in our testing we didn't need the scopes in the credential which has been working for other users as well 🤔

We use the .default scope which should work, I will check this with the rest of the team as well to see what the thoughts are.

[F4brizio]

Hi @Joffcom ,

After running several tests and digging into Microsoft’s docs, I realized that using
https://{subdomain}.sharepoint.com/.default isn’t ideal for n8n.

The problem is that .default only works when the App Registration already has Application permissions consented in the tenant. That means:

• In a multi-tenant scenario, many users just end up with empty tokens because their admins never configured those Application permissions.
• It basically forces an app-only access flow, which doesn’t match the common delegated use case in n8n where each user authenticates with their own account.

Because of that, I switched the approach to using explicit Graph scopes instead, like:
Sites.ReadWrite.All Files.ReadWrite.All User.Read

This way:

• The token reliably includes the delegated permissions needed for SharePoint actions (list, upload, etc.).
• It follows Microsoft’s own guidance for delegated SharePoint access.
• It’s multi-tenant friendly and avoids requiring every admin to pre-consent app-only permissions.

Finally, I validated this with Postman: using the current n8n scope, the token did not request any site permissions and every request to SharePoint endpoints returned unauthorized. With the updated scopes, the token correctly included SharePoint access and requests to SharePoint APIs succeeded.

I believe this makes the credential more usable out of the box for most users, while still leaving the option for advanced setups to override the scope if they want app-only.

[Joffcom]

Hey @F4brizio

What happens if the app permissions are configured as we document which is based on the Microsoft documentation?

I am sure having the scopes in the credentials would make it easier for some but what we have now should work assuming the app is correctly configured in Azure.

Can you share the documentation you were reading so I can include it in our internal chat on this one.

[F4brizio]

Hey @F4brizio

What happens if the app permissions are configured as we document which is based on the Microsoft documentation?

I am sure having the scopes in the credentials would make it easier for some but what we have now should work assuming the app is correctly configured in Azure.

Can you share the documentation you were reading so I can include it in our internal chat on this one.

Sure, the documentation I reviewed was this one:
Scopes and permissions in the Microsoft identity platform.

In that article, Microsoft makes it clear that:

“A third-party app can request these permissions from users and administrators, who must approve the request before the app can access data or act on a user's behalf.”

And also:

“In OAuth 2.0, these types of permission sets are called scopes. … An app requests the permissions it needs by specifying the permission in the scope query parameter.”

This aligns with my findings: when using only /.default, the token did not include SharePoint-related delegated scopes, and requests to SharePoint APIs were unauthorized. But when explicitly requesting scopes such as Sites.Read.All Sites.ReadWrite.All Files.ReadWrite.All openid offline_access User.Read, the consent screen appeared, and SharePoint interactions worked as expected. This matches the documentation’s explanation that explicit scopes must be requested in the scope parameter for delegated scenarios.

Additionally, the article emphasizes:

“If the application requests application permissions and an administrator grants these permissions this grant isn't done on behalf of any specific user. Instead, the client application is granted permissions directly. These types of permissions should only be used by daemon services and other non-interactive applications that run in the background.”

That distinction is important because it shows why .default works in app-only contexts but not when we need delegated user consent for SharePoint access.

I also tested this behavior in Postman: with the current n8n scope setting (/.default), SharePoint routes failed with unauthorized responses. With explicit scopes, the token correctly included SharePoint permissions and requests succeeded.

If changing the default scopes in n8n isn’t an option, I’d suggest at least making the scope field visible and editable in the credentials. This would give users flexibility to adapt depending on whether they need delegated access or app-only, without requiring code changes.

[joestr]

Is there any chance this gets merged?

[logandee]

Hi @Joffcom,

This is specifically an issue for the cloud version of n8n. Because the n8n instance is hosted by n8n the app registration is also managed by n8n and users have no way to configure the appropriate permissions. It requires the app to request the required permission in the external tenant for them to be granted in that tenant. This is why you need to add the scopes to the SharePoint node credential, otherwise the external tenant has no permissions to provide through the .default permission.
More details on requesting permissions

I'm just reiterating on what @F4brizio explained here. Can we please get this merged? The SharePoint node is useless in the cloud version of n8n otherwise.

[Joffcom]

Hey @logandee

The cloud version should be working we updated the Microsoft app and other users are reporting it is now working. If your cloud instance isn't working please restart it and create a new credential.

We have been talking internally about updating the node to move it away from the current rest api and fully over to the graph api which would likely be a better option in the future.

[logandee]

Yep, it's working now! Thanks!

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

[n8n-assistant]

Hey! 👋 There's been no update for 6 months, and it might be our fault.
We're victims of our success: we do our best to handle everybody's expectations, but people and PRs fall through the cracks of our processes.
If you're still interested in this PR, please update your branch and/or address the last comments.
With no update by 14 days, we will close this pull request.
However, this isn't the end. Closed PRs can always be reopened, so nothing is lost. Come back once you'll have more capacity and this time our new triage system should handle it better :)
Thanks for contributing! 🙏

[github-actions]

Closing this PR since the requested changes weren't made. This is just housekeeping — if you'd like to pick it up again, address the feedback and reopen (or open a fresh PR) and we'll happily take another look. Thanks again for the contribution! 🙏