This post was most recently updated on July 26th, 2024.

3 min read.

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.

Description

Table of Contents

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 to 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:

https://graph.microsoft.com/v1.0/sites/[tenant].sharepoint.com:/sites/[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

Solutions

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:

Time needed: 10 minutes

How to enable “owner” permissions for site collection

Re-grant permissions to the app from Azure AD.
That didn’t do anything for me
Make sure that the test users could access the SharePoint site
They could, via browser, without errors.
Add 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)
Grant ALL of the delegated permissions to the app.
This is already quite dirty, but maybe I was missing something. It did not help, though.
Grant “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.

If none of these work for you either, try the next step (which did work for me)
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.

Which of these steps worked for you? Let me know if the comments section!

Author
Recent Posts

Antti K. Koskela

Developer / Speaker / Consultant at Koskila / Precio Fishbone / Norppandalotti Software Co / Alter - Experience Ideas Ltd

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 Solutions Architect for Precio Fishbone, building delightful Digital Workplaces.

He's been a developer from 2004 (starting with PHP and Java), and he's been working on .NET projects, Azure, Office 365, SharePoint and a lot of other stuff. He's also Microsoft MVP for Azure.

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

Latest posts by Antti K. Koskela (see all)