Embed Token Generation Successful, but 403 Forbidden on ExecuteQueries API

[KonradKolenda]

Hi everyone!

I'm running into a frustrating issue with Power BI embed tokens and hoping someone here has encountered this before or can point me in the right direction.

What I'm trying to do
I'm building an application that needs to execute DAX queries programmatically against a Power BI dataset with Row-Level Security. We're using the "embed for customers" approach with service principal authentication in a Premium capacity environment.

My RLS setup
I'm using dynamic RLS with the USERNAME() function. The twist is that we're using non-AD users (what I call "fake users") - just arbitrary strings that don't exist in Azure AD. Microsoft's documentation says this is fine: "username can be any string" and "effective identity can be an arbitrary string".

Our RLS rule looks like this:
tablePermission DimTable =
IF(
USERNAME() = "AdminUser",
TRUE(),
[FilterColumn] = USERNAME()
)

What's working perfectly ✅
Generate Token API works flawlessly:

POST /v1.0/myorg/groups/{workspaceId}/datasets/{datasetId}/GenerateToken
{
"accessLevel": "View",
"identities": [
{
"username": "TestUser", // This is a fake user, not in AD
"roles": ["DataRole"],
"datasets": ["{datasetId}"]
}
]
}

Response: 1900+ character token, valid expiration, no errors at all.

What's broken ❌
ExecuteQueries API consistently returns 403 Forbidden:

POST /v1.0/myorg/groups/{workspaceId}/datasets/{datasetId}/executeQueries
Headers: Authorization: Bearer [the_embed_token_from_above]
{
"queries": [
{
"query": "EVALUATE ROW(\"Value\", [SomeMeasure])"
}
]
}

Result: 403 Forbidden every single time.

What I've tested
- "TestUser" (should see filtered data) → 403 Forbidden
- "AdminUser" (should bypass RLS completely) → 403 Forbidden
- Different DAX queries → Same 403 error
- Token validation → Token is valid, not expired

The fact that even "AdminUser" (which should see everything) gets 403 makes me think this isn't an RLS filtering issue, but rather an authentication/authorization problem.

What works as a comparison
If I use the service principal token directly (not the embed token) with ExecuteQueries, it works fine - but of course, I lose the RLS context completely.

My questions
1. Has anyone successfully used embed tokens with the ExecuteQueries REST API? Especially with non-AD users?

2. Is there something special about Premium capacity that I might be missing for this scenario?

3. Are there additional permissions needed beyond what allows successful token generation?

4. Could this be a limitation where embed tokens work for report embedding but not for direct dataset queries?

Environment details
- Premium capacity (so no token limits)
- Service principal has workspace access (proven by successful token generation)
- Same service principal works fine for other Power BI REST operations
- Using .NET Core application, but I've tested with PowerShell scripts too

I'm starting to think there might be an API compatibility issue here, but before I go down that rabbit hole, I wanted to check if anyone in the community has made this work.

Any insights, experiences, or even just confirmation that "yeah, that doesn't work" would be incredibly helpful!

Thanks in advance! 🙏

[KonradKolenda]

Hi @v-veshwara-msft ,

Thank you for you answer.

I do have a follow-up question though, and I'm hoping you can help us figure out the best path forward.

We've been following Microsoft's guidance pretty closely, and according to your documentation, we should be using service principal authentication - [implementation planning guide](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-implementation-planning-usage-scenario-e...) is pretty clear about this:

"We recommend using a service principal for production apps. It provides the highest security and for this reason it's the approach recommended by Microsoft Entra ID."

We're also using "arbitrary usernames" approach which are users that don't exist in Azure AD. [Cloud RLS documentation](https://learn.microsoft.com/en-us/power-bi/developer/embedded/cloud-rls)  docs say this is totally fine: "when you generate the embed token, you need to supply a username, but the username can be any string".

Here's where I'm getting stuck:
- Service Principal authentication = Microsoft recommended ✅
- Non-AD usernames for RLS = Officially supported ✅
- ExecuteQueries API = What we need for direct dataset access ✅
- All three working together = Apparently not possible? ❌

So my question is: How are we supposed to do RLS with arbitrary usernames when using executeQueries with service principal authentication?

Is there a way to pass the user identity context in the executeQueries request body? Or should we be using a completely different approach for this scenario?

I feel like we're trying to follow all the "right" Microsoft patterns, but they don't seem to play nicely together for our use case. Any guidance on how to make this work (or if there's a better approach) would be really helpful!

[v-veshwara-msft · Accepted solution]

Hi @KonradKolenda ,

Thanks for sharing the additional details. You are correct that the guidance recommends using a service principal for production apps and that the documentation indicates arbitrary strings can be used for RLS when generating embed tokens.

The executeQueries API examples are shown with Azure AD access tokens from a service principal or master user, and there does not seem to be a way to pass an arbitrary identity through that API call in the same way it is done when generating an embed token. This may explain why the combination of service principal, arbitrary usernames, and executeQueries is not working as expected.

Based on research and documentation, the executeQueries endpoint does not appear to support supplying an effective identity in the request body. That option is described only in the context of token generation for embedding. If the main requirement is enforcing RLS with non-AD usernames, embedding reports or using embed tokens may still be the supported approach. For programmatic queries, alternatives like XMLA endpoints could be considered, but those require valid AAD identities and do not accept arbitrary strings.

This seems to be a gap between the supported scenarios, and if this combination is critical for your use case it may be best to raise it through support ticket to confirm whether there is a way planned to enable it.

Hope this helps. Please reach out for further assistance.

Thank you.

[v-veshwara-msft]

Hi @KonradKolenda ,

Thanks for posting your question in the Microsoft Fabric Community and for providing a clear explanation of your setup.

It seems that the executeQueries API may not work with embed tokens. Embed tokens are generally meant for embedding reports or dashboards, while running dataset query APIs such as executeQueries may require an Azure AD access token issued to a service principal or master user. This may be the reason you are seeing a 403 error when using an embed token.

Also, based on the documentation, embed tokens are described in the context of embedding reports, dashboards, and datasets in applications. The executeQueries API, on the other hand, is documented under dataset operations and the examples there use Azure AD tokens from a service principal or master user.

For reference, you can review the embed token documentation here:
https://learn.microsoft.com/en-us/rest/api/power-bi/embed-token/generate-token

And the executeQueries API reference here:
Datasets - Execute Queries - REST API (Power BI Power BI REST APIs) | Microsoft Learn

Hope this helps. Please reach out for further assistance.

Thank you.