SharePoint 403 Error trying to get List of Folder Items

This page explains the case where an application successfully gets an OAuth2 access token, but then fails with a 403 permissions error when trying to download a list of folder items in SharePoint.

It is almost certainly a SharePoint / Azure AD permissions issue, not a programming error in the application.

What's Working Perfectly

  1. Authentication - You are successfully sending your credentials (likely a client ID and client secret) to the Microsoft identity platform and receiving a valid OAuth2 Bearer token.
    • The Response status code = 200 and the JSON payload with the access_token clearly prove this. This is the hardest part, and you've got it working. This means your Tenant ID, Client ID, and Client Secret are all correct.
  2. Connection - Your code is successfully making an HTTPS connection to the SharePoint server (example.sharepoint.com).
    • The log shows HTTPS secure channel established, meaning the low-level network communication is fine.

The Core of the Problem: 403 Forbidden

A 403 Forbidden error is very different from a 401 Unauthorized error.

  • 401 Unauthorized means: I don't know who you are. You haven't provided valid credentials.
  • 403 Forbidden means: I know exactly who you are (based on the token you provided), but the identity you represent does not have permission to perform the action you are requesting on this resource.

Since you are successfully getting a token and then immediately getting a 403, it means the token was likely sent correctly, but the permissions encoded within that token are insufficient for reading items from that SharePoint folder.

Insufficient API Permissions (Very Likely)

This is the most common reason for a 403 Forbidden error in this scenario. When you register an application in Azure Active Directory (now Microsoft Entra ID) to access SharePoint, you must explicitly grant it permissions (called scopes) to perform specific actions.

The token you receive contains information about these granted permissions. When SharePoint receives your request, it inspects the token and says, Does this application have permission to read site items? If the answer is no, it returns 403 Forbidden.

Actionable Steps for You and Your SharePoint/Azure Administrator:

You need to check the API Permissions for your Application Registration in the Azure AD / Entra ID portal.

  1. Go to portal.azure.com -> Microsoft Entra ID -> App registrations.
  2. Find the application you are using (by its Client ID).
  3. Go to the API permissions section.
  4. Look for permissions under SharePoint. You will need permissions sufficient to read files. Common permissions include:
    • Sites.Read.All (Allows the app to read items in all site collections)
    • Files.Read.All (Allows the app to read files in all site collections)
  5. Crucially, check the Type. Are you using Delegated or Application permissions?
    • Delegated: The app acts on behalf of a signed-in user. The app can only do what the user can do.
    • Application: The app acts on its own (like a background service). This is common for server-to-server calls using a client secret. The permissions are granted directly to the app itself. Your authentication flow (using a client secret) suggests you need Application permissions.
  6. THE MOST IMPORTANT STEP - After adding the required permissions, an Azure AD administrator MUST grant admin consent for those permissions. In the API permissions screen, there is a button that says Grant admin consent for [Your Tenant]. If the status next to your SharePoint permission does not have a green checkmark and says Not granted, then the permission is not active, and you will always get a 403 error.

Another Quick Tip: Simplify Your Test URL

The URL /_api/web/GetFolderByServerRelativeUrl('/Home')/items is quite specific. It's possible the path /Home is incorrect or refers to a page, not a document library.

To isolate the problem, try a much simpler API call first:

https://costsmaster.sharepoint.com/_api/web

This URL just requests basic information about the site itself. It requires the most basic Sites.Read.All permission. If this simple URL also fails with a 403, you know for certain it's a fundamental permission problem. If it succeeds, then the issue might be with the folder path in your original, more complex URL.