Forum Discussion
PowerBI dynamic OAUTH token using Entra App - Expression.Error: Access to the resource is forbidden.
- 6 months ago
Hi Scott,
Thanks for the clarification — that helps narrow things down a lot.
If you are using Delegated permissions and targeting Admin APIs (like GetGroupsAsAdmin / tenant-level listing), then you are correct that the Service Principal does not need to be added to individual workspaces. That requirement is mainly for workspace-scoped APIs.
However, in Admin API scenarios, there are a couple of important nuances that often cause the Forbidden result even when the token generation itself works.
Key Things to Validate for Admin APIs
1️⃣ Delegated Token Must Belong to a Power BI Admin (or equivalent role)
If you are using delegated auth, the signed-in identity behind the token must be:Power BI Service Admin
ORGlobal Admin (or Fabric equivalent depending on tenant config)
If the token is valid but the user is not admin-level → Admin APIs will return Forbidden.
2️⃣ Admin APIs May Require Explicit Enablement
Power BI Admin Portal → Tenant Settings → Developer Settings
Look for settings like:
✔ Allow service principals to use Power BI APIs
✔ Allow service principals to use read-only admin APIs (if enabled in your tenant)Some tenants separate standard API vs Admin API SPN access.
3️⃣ Delegated vs Application — Important Design Note
For Admin reporting automation, Microsoft generally recommends:
👉 Application Permissions + Client Credential Flow
Instead of DelegatedBecause delegated flows can fail if:
User context changes
MFA / conditional access kicks in
Admin privilege not present in token claims
4️⃣ Token Claim Validation (Very Useful Here)
If you decode the failing token in jwt.ms, check:
roles → present if Application permissions
scp → present if Delegated
aud → must be Power BI API
upn / oid → should map to an admin identity (delegated case)
If this is delegated + Admin API → most common root cause is:
👉 Token user is not Power BI Admin
👉 Or Admin API SPN usage is not enabled tenant-sideBased on What You Said — Most Likely Scenarios
Since:
✔ Scope correct
✔ Token generates fine
✔ Manual token works
✔ You are calling Admin APIs
✔ SPN not in workspace (which is fine here)The top 2 likely causes are:
⭐ Delegated token user not Power BI Admin
⭐ Tenant Admin API permissions for SPN / automation not fully enabledIf you’re open to sharing, these would help pinpoint quickly:
Which exact Admin endpoint are you calling?
Are you testing delegated token under a Power BI Service Admin user?
Are you planning long-term automation (no user context)? → If yes, Application permissions is usually safer.
Hope this helps — you are very close.
I think there are a number of things in that list for me to go through.
Scope is correct though
Access I have as delegated
and no SPN is not adde dto Workspace as this is admin API and I want to list all workspaces
Hi Scott,
Thanks for the clarification — that helps narrow things down a lot.
If you are using Delegated permissions and targeting Admin APIs (like GetGroupsAsAdmin / tenant-level listing), then you are correct that the Service Principal does not need to be added to individual workspaces. That requirement is mainly for workspace-scoped APIs.
However, in Admin API scenarios, there are a couple of important nuances that often cause the Forbidden result even when the token generation itself works.
Key Things to Validate for Admin APIs
1️⃣ Delegated Token Must Belong to a Power BI Admin (or equivalent role)
If you are using delegated auth, the signed-in identity behind the token must be:
Power BI Service Admin
ORGlobal Admin (or Fabric equivalent depending on tenant config)
If the token is valid but the user is not admin-level → Admin APIs will return Forbidden.
2️⃣ Admin APIs May Require Explicit Enablement
Power BI Admin Portal → Tenant Settings → Developer Settings
Look for settings like:
✔ Allow service principals to use Power BI APIs
✔ Allow service principals to use read-only admin APIs (if enabled in your tenant)
Some tenants separate standard API vs Admin API SPN access.
3️⃣ Delegated vs Application — Important Design Note
For Admin reporting automation, Microsoft generally recommends:
👉 Application Permissions + Client Credential Flow
Instead of Delegated
Because delegated flows can fail if:
User context changes
MFA / conditional access kicks in
Admin privilege not present in token claims
4️⃣ Token Claim Validation (Very Useful Here)
If you decode the failing token in jwt.ms, check:
roles → present if Application permissions
scp → present if Delegated
aud → must be Power BI API
upn / oid → should map to an admin identity (delegated case)
If this is delegated + Admin API → most common root cause is:
👉 Token user is not Power BI Admin
👉 Or Admin API SPN usage is not enabled tenant-side
Based on What You Said — Most Likely Scenarios
Since:
✔ Scope correct
✔ Token generates fine
✔ Manual token works
✔ You are calling Admin APIs
✔ SPN not in workspace (which is fine here)
The top 2 likely causes are:
⭐ Delegated token user not Power BI Admin
⭐ Tenant Admin API permissions for SPN / automation not fully enabled
If you’re open to sharing, these would help pinpoint quickly:
Which exact Admin endpoint are you calling?
Are you testing delegated token under a Power BI Service Admin user?
Are you planning long-term automation (no user context)? → If yes, Application permissions is usually safer.
Hope this helps — you are very close.
- v-aatheeque6 months agoCommunity Support
Hi scott_dunk
Have you had a chance to look through the responses shared earlier? If anything is still unclear, we’ll be happy to provide additional support.- v-aatheeque6 months agoCommunity Support
Hi scott_dunk
Following up to confirm if the earlier responses addressed your query. If not, please share your questions and we’ll assist further.