SharePoint Embedded: container type registration grants can take hours to propagate, and the 403 is indistinguishable from a permanent misconfiguration

[venturemavenwill]

Important

Corrected. The managed-identity root cause below is wrong — see the correction comment. The managed identity works; the grant simply took 1–2.5 hours to propagate. The real issue is that a bare 403 accessDenied cannot be told apart from a permanent misconfiguration during that window. Original text kept below for the record.

---

Pages this affects

• Configure authentication and authorization — "Configure app-only token acquisition"
• Plan authentication and permissions
• Troubleshooting — the "Access denied when calling container or file APIs" row

Summary

I built a SharePoint Embedded app hosted on Azure Container Apps and tried to
use its user-assigned managed identity for app-only access, since that means
the app holds no credential at all. Every requirement the documentation states
was satisfied and verified, and the call failed with a bare 403 accessDenied
giving no indication of which layer refused.

A controlled comparison shows that an Azure managed identity is refused where
an ordinary Entra app registration with identical permissions succeeds. The
documentation never mentions managed identities — it neither supports nor rules
them out — so there was no way to know this short of testing it.

What the docs currently say

"Configure app-only token acquisition":

1. Configure an application credential, such as a certificate.
2. Request application FileStorageContainer.Selected.
3. Have a consuming tenant administrator grant admin consent.
4. Acquire a token using the client credentials flow.

"such as a certificate" reads as an example, not a constraint.

"Plan authentication and permissions":

The owning app must have a service principal installed on the consuming tenant.

A managed identity is a service principal, so this reads as satisfied.

Searching the SharePoint Embedded doc set for "managed identity" returns
nothing at all.

The controlled comparison

Three callers, same tenant, same container type, same request. All three held
Graph application role FileStorageContainer.Selected (verified present in the
issued token's roles claim) and all three were granted
applicationPermissions: ["full"] in the same container type registration:

Caller	Identity type	Owns the container type	roles in token	Result
Owning app, certificate	App registration	Yes	FileStorageContainer.Selected	200 OK
Guest app, certificate	App registration	No	FileStorageContainer.Selected	200 OK
User-assigned managed identity	Managed identity	No	FileStorageContainer.Selected	403 accessDenied

The guest app registration rules out container type ownership as the cause: a
non-owning app registration works fine. The only remaining difference is the
identity type — servicePrincipalType: ManagedIdentity versus Application.

The request:

GET https://graph.microsoft.com/v1.0/storage/fileStorage/containers?$filter=containerTypeId eq {containerTypeId}

The managed identity's response:

403 {"error":{"code":"accessDenied","message":"Access denied",
     "innerError":{"date":"...","request-id":"...","client-request-id":"..."}}}

A second finding, which made this much harder to diagnose

When I first granted the guest app registration, it returned the exact same
bare 403 accessDenied. It began working roughly three minutes later with no
change on my side — the container type registration grant simply hadn't
propagated yet.

So the identical error means both:

• "this will start working shortly, wait", and
• "this will never work, the caller type is unsupported"

with nothing in the response to tell them apart. During the propagation window
I had a false negative that looked exactly like the permanent failure. Anyone
testing a new grant can easily conclude their setup is wrong when it's simply
not ready, or conclude they need to wait when in fact they need a different
credential type.

Why the current troubleshooting entry doesn't help

Access denied when calling container or file APIs. — Likely cause: the
container type hasn't been registered in the consuming tenant, or the
application lacks container type application permissions.

Both listed causes were verified as not applicable. The row offers nothing
further, so following it leads to re-checking two things that are already
correct.

Suggested changes

1. State that managed identities aren't supported callers, on "Configure
   app-only token acquisition". One sentence would have saved a lot of time:

   App-only access requires an Entra ID application registration with a
   certificate or client secret. Azure managed identities aren't supported as
   SharePoint Embedded callers.

   This matters because a managed identity is the credential-free option, and is
   what Azure guidance steers you toward everywhere else — so it's a natural
   first choice for an app hosted on Azure, and the one that silently fails.

2. Document the propagation delay on container type registration. Something
   like: "Grants can take several minutes to take effect. During this window,
   calls return 403 accessDenied. Retry before concluding the grant is wrong."

3. Add a Troubleshooting row for when everything checks out:

   Access denied on container APIs after confirming registration and
   container type permissions. — Likely cause: the grant hasn't propagated
   yet, or the caller isn't a supported identity type. Retry after several
   minutes; if it persists, confirm the caller is an app registration rather
   than a managed identity.

4. Distinguish the causes in the error (a product ask, not a docs one, but
   it's the root of the cost). accessDenied with an empty innerError is
   currently identical across at least five distinct situations: missing Graph
   role, missing admin consent, unregistered container type, unpropagated grant,
   and unsupported caller type. Naming which layer refused — even just "Graph
   permission" versus "container type permission" — would remove nearly all of
   the guesswork here.

Environment

• Microsoft Graph v1.0, /storage/fileStorage/containers
• Trial container type, developer tenant
• Failing caller: user-assigned managed identity on Azure Container Apps, token
  from the platform identity endpoint with an explicit client_id
• Working callers: two Entra app registrations (one owning the container type,
  one not), both using certificate credentials and the client credentials flow

[venturemavenwill]

Correction: the managed identity does work — please disregard the root cause above

I need to correct this issue. The claim that an Azure managed identity can't be used for app-only access is wrong, and I'd rather retract it than leave it sitting in your backlog.

The same managed identity that was returning 403 accessDenied is now working, with no change to its Graph app role and no change to its container type grant:

storage: mode=sharepoint-embedded  auth=managed identity (no secret)

Verified on a fresh credential acquisition after a full application restart, with zero fallbacks used.

What actually happened

Time (UTC)	Event
~13:20	Managed identity granted the Graph role and application: ["full"] on the container type
13:40	GET /storage/fileStorage/containers → 403 accessDenied
14:29	Container type registration re-written (unrelated change)
14:32	Fresh token, fresh process → still 403
~15:0x	Container type registration re-written again
~15:55	Same identity, same permissions → 200 OK

So this was a propagation delay of somewhere between one and two and a half hours, not an unsupported caller type.

A confound I can't rule out: I re-wrote the container type registration twice in that window (adding, then removing, an unrelated guest app). Either PUT may have re-applied the managed identity's grant rather than time alone being the cure. I can't separate those two explanations from the outside, and I'd rather say so than guess.

What the real issue is

The second finding in my original report turns out to be the whole story, and it's worth more than the thing I got wrong.

I saw the identical bare 403 accessDenied in two situations that needed opposite responses:

• a guest app registration, which started working ~3 minutes later on its own
• this managed identity, which took 1–2.5 hours (and possibly a registration re-write)

In both cases the response was byte-identical, with an empty innerError. There is no way to tell "this grant hasn't propagated yet, wait" from "this configuration is wrong, change it". I spent a working day building a second and third identity to bisect a problem that was, in the end, just latency — and I reached a confidently wrong conclusion because a two-hour wait doesn't look like a wait, it looks like a refusal.

Revised suggestions

1. Document the propagation delay on container type registration, with a realistic upper bound. Something like: "Grants can take up to N hours to take effect. During this period, calls return 403 accessDenied. Verify the grant is present via the registration API and retry before changing your configuration." If the expected latency really is hours, saying so plainly would prevent exactly the failure I walked into.

2. Distinguish "not yet propagated" from "not permitted" in the error. Even a distinct innerError.code would be enough. Right now accessDenied with an empty innerError covers at least: missing Graph role, missing admin consent, unregistered container type, unpropagated grant, and genuine denial.

3. Add a Troubleshooting row for: access denied after the registration API confirms the grant is present → likely propagation; retry before reconfiguring.

4. Please disregard my earlier suggestion to document managed identities as unsupported. They work.

Separate, still-valid observation

POST /drives/{id}/items/{id}/lock and /releaseLock (beta) return 400 invalidRequest / apiNotFound on SharePoint Embedded container drives, even though the driveItem: lock reference carries a SharePoint Embedded permissions note implying support. That note is misleading if the endpoints aren't routable for SPE drives.

Apologies for the noise on the original diagnosis.