This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
I am creating an Application Registration using the Graph C# SDK, but I keep getting errors when creating a service principal for that new App ID I created. I am using the permission "Application.ReadWrite.OwnedBy".
This is the error response I get from the Graph API:
{"code":"Authorization_RequestDenied","message":"When using this permission, the backing application of the service principal being created must in the local tenant","innerError":{"date":"...","request-id":"...","client-request-id":"..."}}
This error is very recent. Previously, I could create the app registration + service principal with this permission. I saw related issues in the Azure CLI GitHub: https://github.com/Azure/azure-cli/issues/14767
I understand the architecture has replication : https://learn.microsoft.com/en-us/entra/architecture/architecture but the error message doesn't help a lot. I'm not sure if it's a permissions problem or something else.
Can anyone help?
Thanks!
An API that connects multiple Microsoft services, enabling data access and automation across platforms
Can you share the full payload and the decoded access token (redact any sensitive data)? 403 usually mean missing permissions, so we need to verify whether the calling principal has been assigned sufficient permissions and has the required Entra ID roles, as appropriate.
Hi Vasil, I can share a snippet of the access token with redacted info:
{
"typ": "JWT",
"nonce": "REDACTED",
"alg": "RS256",
"x5t": "REDACTED",
"kid": "REDACTED"
}.{
"aud": "https://graph.microsoft.com",
"app_displayname": "REDACTED",
"idtyp": "app",
"roles": [
"Application.ReadWrite.OwnedBy",
"REDACTED"
],
"ver": "1.0"
}
Also here is the request payload:
{"@odata.type":"#microsoft.graph.servicePrincipal","appId":"REDACTED"}
Again, the roles have the Application.ReadWrite.OwnedBy, which should work. It also has another role I need but it's not for the "Application". It worked before, in the docs it says I can use this permission to create a service principal for the app registration i created before. The audience is correct and set to graph API.
I see these errors at least since April 8th, so it shouldn't be a permissions problem. Can you help, or do you need anything else?
Thanks!
Can you share a sample payload as well? I'm trying to reproduce the issue, but it seems to work OK for me.
Are you provisioning a multi-tenant app? Are you tying to provision the SP in the home tenant or a different one?
Here is the request payload: {"@odata.type":"#microsoft.graph.servicePrincipal","appId":"REDACTED"}.
As far as I can tell, this is a single tenant only application registration. The C# SDK code to create the app registration is this:
Application application = new Application()
{
DisplayName = name
};
await graphClient.Applications.PostAsync(application);
The SP is being provisioned in the same tenant as the application registration.
Thanks. Yes, a single-tenant app should be created by default, when you pass only the app name. I am still unable to reproduce this though, and I cannot point to any fault in your requests/payload/permissions.
Do you have any option to test it in a different tenant?
No I can't test with another tenant sorry. But in fact this 403 error and other 400 requests (Not a valid reference update) I'm having seems due to replication issues and eventual consistency. I would prefer to have 100% clarity on why this happens.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(105.60000000000001, 48%, 20%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ELC%3C/text%3E%3C/svg%3E)
We do encounter the similar issue , we have a service principal with the Application.ReadWrite.OwnedBy and Cloud Application Administrator .
The replication delay maybe the issue , after completing the app registration, an immediate call of creating service principal often results in error When using this permission, the backing application of the service principal being created must in the local tenant due to hitting a cold replica, i think it is better to add a polling / retry function as a guard, making it less likely to hit the cold replica.
The Chain of Our Application
1. App registration : POST /applications
↓ replication delay
2. Create Service Principal : POST /servicePrincipals ← [Guard 1: waitForOwnership polls owners endpoint]
↓ replication delay
3 . Create Federated Credentials: POST /applications/{id}/federatedIdentityCredentials ← [Guard 2: retry loop on 404]
I am not sure but after setting Application.ReadWrite.All slightly help to resolve this issue but again this is not ideal due to the security issue of write all.
Problem of the cold replica (Not too sure if i am correct)
Problem 1 — SP creation fails:
POST /applications writes to Region A. Azure AD auto-adds the backend SP as owner of that app, but POST /servicePrincipals lands on Region B (cold replica). Region B sees: "you're trying to create an SP for an app you don't own" → rejected under OwnedBy.
→ waitForOwnership polls GET /applications/{id}/owners until Region B catches up.
Problem 2 — Federated credential creation fails:
Even after ownership is confirmed, POST /applications/{id}/federatedIdentityCredentials can land on Region C — a completely different cold replica that hasn't received the app object at all yet → 404 Request_ResourceNotFound.
→ Retry loop retries until Region C catches up.
Thanks Luis for confirming you have the same issue. I have the same doubts as you, i am not 100% sure it's replication and can't confirm it. Error messages don't always help. But it might be a cold replica yes.
Again, I read these 2 posts so this is most likely a replication latency issue because Microsoft Entra is eventually consistent.
I've added polling/retry logic of like 5-6min and it still is not enough sometimes. Because you can retry and get a 200 OK response, but that response can probably be from another replica that has that object already. When you make the POST request after getting that 200 OK, you can probably still hit a cold replica and get errors... Kind of sad :(
You would need a system that makes sure you get a 200 OK for a given object on every single read replica, every single datacenter perhaps.