Forum Discussion

scott_dunk's avatar
scott_dunk
Frequent Visitor
6 months ago
Solved

PowerBI dynamic OAUTH token using Entra App - Expression.Error: Access to the resource is forbidden.

Hi,

 

I am trying to setup some admin reports using the PowerBI API's.

 

I can connect to the data using my own cut and past token and now need to setup dynamic  token being pased to API call.  Steps I have completed:

  • Created Entra App - enabled for workspace read
  • Confirmed features in PBI Service portal are enabled to allow SPN to use API's
  • confirmed in postman that it returns token using client id, secret, scope
  • Create function in PBI Desktop that returns the token
  • Tested PowerBI connection using my own token, works fine
  • Tested PowerBi using generated token from ENtra App and I get the Access is Forbidden Error

 

Please help as I have been going round in circles for 2 days 🙂

 

Thanks,

Scott.

Need Help
  • bariscihan's avatar
    bariscihan
    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
      OR

    • Global 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.

6 Replies

  • bariscihan's avatar
    bariscihan
    Resolver II
    6 months ago

    From what you described, the “Expression.Error: Access to the resource is forbidden” is most likely not an authentication issue, but an authorization / permission scope issue between the Service Principal token and the Power BI resource.

    In Power BI API scenarios, successfully generating an OAuth token does not automatically mean the token is authorized to access Power BI resources. If a manual user token works but the Entra App token returns Forbidden, this usually indicates missing permissions, missing admin consent, or missing workspace-level access for the Service Principal.

    ✅ Recommended Best Practice Checklist

    1️⃣ Use Application Permissions (Not Delegated)
    For Service Principal based automation, make sure the Entra App uses Application permissions under Power BI Service API.

    Typical required permissions depend on the scenario, but commonly include:

    • Tenant.Read.All

    • Capacity.Read.All

    • Workspace.Read.All

    • Dataset.Read.All

    2️⃣ Grant Admin Consent
    Even if permissions are added, they must be tenant-approved:
    Azure Portal → Entra App → API Permissions →
    👉 Grant Admin Consent

    Without this, the token can be generated but Power BI will reject resource access.

    3️⃣ Validate Power BI Tenant Settings
    Power BI Admin Portal → Tenant Settings:

    Ensure enabled:

    • Allow service principals to use Power BI APIs

    • Allow service principals to create workspaces (optional but recommended for automation scenarios)

    4️⃣ Add Service Principal to Workspace
    This is one of the most common root causes.

    Even if tenant settings and permissions are correct, the SPN must be explicitly added to the workspace:

    Power BI Service → Workspace → Access →
    Add Service Principal → Member / Admin (based on need)

    5️⃣ Validate OAuth Scope
    Recommended scope when requesting tokens:

    https://analysis.windows.net/powerbi/api/.default

    Using Graph or other scopes will result in valid tokens but no Power BI access.

    6️⃣ Decode and Validate Token Claims
    Use https://jwt.ms to validate:

    • audience (aud) → should be Power BI API

    • roles → should include Power BI roles

    • scp → if delegated is mistakenly used

    🧠 Architecture Best Practice (Production)

    For enterprise automation scenarios:

    ✔ Use Service Principal + Application Permissions
    ✔ Manage workspace access via security group (recommended for scalability)
    ✔ Store secrets in Azure Key Vault
    ✔ Use .default scope with client credential flow
    ✔ Implement token caching to reduce auth overhead

    📚 Microsoft Reference Documentation

    Power BI + Service Principal Authentication
    https://learn.microsoft.com/power-bi/developer/embedded/embed-service-principal

    Power BI REST API Authentication
    https://learn.microsoft.com/power-bi/developer/embedded/embed-tokens

    Enable Service Principal Access in Power BI
    https://learn.microsoft.com/power-bi/admin/service-admin-portal-developer

    OAuth 2.0 Client Credentials Flow (Microsoft Identity Platform)
    https://learn.microsoft.com/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow

    ⭐ Summary

    If manual tokens work but Service Principal tokens return Forbidden, the issue is almost always one of:

    • Missing Application Permission

    • Missing Admin Consent

    • Service Principal not added to workspace

    • Incorrect OAuth scope

    If you can share:

    • Token scope

    • Permission type (Delegated vs Application)

    • Whether SPN is added to workspace

    it would be easier to pinpoint the exact root cause.

    Hope this helps.

    • scott_dunk's avatar
      scott_dunk
      Frequent Visitor
      6 months ago

      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

      • bariscihan's avatar
        bariscihan
        Resolver II
        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
          OR

        • Global 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.