Thanks for your response @v-nmadadi-msft !
I checked out the link you sent (Embed Power BI report in a Power BI embedded analytics application for your customers - Power BI | M...) but it doesn't mention any best practice when it comes to DirectQuery reports with this identityBlob.
The issue is occurring with the Power BI API endpoint "GenerateToken" and can be replicated for example in Postman for example by making a POST request to:
https://api.powerbi.com/v1.0/myorg/groups/<WORKSPACE_ID>/reports/<REPORT_ID>/GenerateToken
(replace <WORKSPACE_ID>, <REPORT_ID>, and <DATASET_ID> with real values), and with this body:
{
"accessLevel": "View",
"identities": [
{
"datasets": [
"<DATASET_ID>"
],
"identityBlob": {
"value": "eyJ0eX....AAA="
}
}
]
}
(just with a real value for the identityBlob ). If the identityBlob value exceeds 10,240 bytes, the API returns the following error: "Identity blob value size exceeds size limit of 10240 bytes". This error occurs regardless of whether the report uses a DirectQuery dataset.
Observations
I tested this issue with a colleague who has fewer Azure AD group memberships than me. When using his access token in the identityBlob, the API successfully returned an embed token, since that token was smaller.
(In fact, any string under 10,240 bytes can be passed into identityBlob to get an embed token—but authentication inside the embedded report to the database would fail if it's just a ranom value). So it seems that this functionality only works for users with very few AD group memberships. Since my Azure SQL token contains a few extra AD groups in the "groups" claim, it becomes too large to use in the identityBlob.
Trying to solve this, I tested different OAuth authentication flows to obtain an Azure SQL access token using scope: "https://database.windows.net//.default" to see if that made any difference regarding the claims in the token.
Results from the different autentication flows:
- Authorization Code Flow with PKCE → Token includes full "groups" claim (too large).
- On-Behalf-Of (OBO) Flow → Token includes full "groups" claim (too large).
- Implicit Flow → Token does NOT include full "groups", but instead has "hasgroups": "true".
When I hardcoded an Azure SQL token obtained via Implicit Flow into my app and used it as value in the identityBlo, I was finally able to access the Power BI report data using DirectQuery 😀
Problem: Avoiding Double Authentication
- Users already authenticate using Authorization Code Flow with PKCE, scoped to my backend API’s App Registration.
- I don’t want to prompt users again to obtain an Azure SQL token using Implicit Flow.
- Using OBO Flow to obtain an Azure SQL token results in a token that’s too large in most cases.
Questions
- Is there a way to obtain an Azure SQL access token for this identityBlob with "hasgroups": "true" instead of the full "groups" claim—without requiring users to authenticate twice using Implicit flow?
- Are there any other projects with similar usecase that has solved this issue?
