Call to sites Graph API requires “owner” permissions for site collection regardless of app permissions

This post was most recently updated on March 20th, 2018.

Reading Time: 3 minutes.

Okay – yet another weird issue, and a hacky workaround. I was developing an app that was calling a SharePoint site through Graph API, using jQuery $.ajax call (developed in TypeScript), and ran into surprising 401 errors. I did find a workaround, but am also working on an actual fix.


To get SharePoint site ID, which is needed when accessing SharePoint lists, the calls seemed to fail for my test accounts. Everything was working fine for my developer account, which was a global admin, so the first thing I was suspecting was of course permissions…

The first offending test account was a Group member, and a restricted reader in the site collection I was trying to access via Graph. The account was also a contributor on the root site of the tenant. And all of my accounts were licensed with E3/E5.

I knew that this part of the code was supposed to get a site id for a certain SharePoint site collection with a call to Graph API, similar to this one:<tenant><site>/

It worked for my developer account, but just wouldn’t work for the test accounts! This is the error I got:

 "error": {
 "code": "unauthenticated",
 "message": "Access denied. You do not have permission to perform this action or access this resource.",
 "innerError": {
 "request-id": "<guid>",
 "date": "2017-12-18T22:57:18"

I found this quite weird, as all the other calls to Graph API worked just fine. I was definitely authenticated just fine, as even with Graph Explorer everything else seemed to work. Just not the sites call (using /beta endpoint instead of /v1.0 didn’t change that).

You can even repro the issue in Graph Explorer:

Unauthorized call to /sites in Graph Explorer
Unauthorized call to /sites in Graph Explorer



Okay, so I’m still investigating this, but I found a solution.. Or rather a dirty workaround! If I find actual solutions, I’ll be adding them below. Comparing the behavior to another site collection revealed, that it’s not consistent – some sites work with reader -permissions, some require owner -permissions… So there’s surely some kind of a setting or a switch that I’ve missed here!

Solutions that didn’t work for me (but might work for you)

Well, I tried the obvious steps first:

  1. Re-granted permissions to the app from Azure AD. That didn’t do anything.
  2. Made sure the test users could access the SharePoint site I was trying to call. They could, via browser, without errors.
  3. Added some more permissions to those accounts – namely, from restricted reader -> contributor, and invited to Style Library and Reusable Content (which were the 2 lists I was going to call)
  4. Granted ALL of the delegated permissions to my app. This is already quite dirty, but maybe I was missing something? Did not help, though.
  5. Granted “Full Control”-permissions to SharePoint Sites in Graph API for the application. This is already app permissions, not delegated anymore, so it should’ve worked. Did not.

So, yeah. In short, everything failed!

Solution that DID work: Add Owner-level permissions to the offending account

Someone could maybe call granting the app ALL delegated permissions, and even Full Control app permissions ridiculous. But the fix is actually (kind of) even more ridiculous. To access site X via Graph API, my test account had to have _at least_ Owner-level permissions on the site. Site Collection Administrator permissions worked, too.



Antti K. Koskela

Antti Koskela is a proud digital native nomadic millennial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as a Solutions Architect for Valo Intranet, the product that will make you fall in love with your intranet. Working with the global partner network, he's responsible for the success of Valo deployments happening all around the world.

He's been a developer from 2004 (starting with PHP and Java), and he's been bending and twisting SharePoint into different shapes since MOSS. Nowadays he's not only working on SharePoint, but also on .NET projects, Azure, Office 365 and a lot of other stuff.

This is his personal professional (e.g. professional, but definitely personal) blog.

Leave a Reply

1 Comment threads
3 Thread replies
Most reacted comment
Hottest comment thread
3 Comment authors
victorAntti K. KoskelaMyManTheDudeRocks Recent comment authors
newest oldest most voted
Notify of

That isn’t a solution. A solution would be something that doesn’t require owner permissions on a site collection.