401 error code only when trying to Export a report

[misterwalrus]

Hi, 

I can get an access token using oauth, with my client_id and my master user/password.   Using that token I can use it  to get a list of all my respots using  the entrypoint  groups ("https://api.powerbi.com/v1.0/myorg/groups").

But I get a 401 error code if I try to use the same token (or even acquire a brand new one) to access this other entrypoint: 

https://api.powerbi.com/v1.0/myorg/reports/<report_id>/Export  

My application has already these permissions granted:  Report.Read.All.

I know that the issue is the token, because I can get a valid token using "Connect-PowerBIServiceAccount   and entering the master user credentials, then I get the token by issuing a Get-PowerBIAccessToken -AsString and use it on my script.  Then I am able to export the report with no issues.

Please, give me some idea of what I am missing here. 

Thank you very much,

Andres

[misterwalrus · Accepted solution]

Soution:   I was using the endpoint:  https://api.powerbi.com/v1.0/myorg/reports/<report_id>/Export      

That endpoint works perfectly with the master password, becuase it refers to my workspace.   

But when using a service principal, you don't have a "My workspace"  to export from.  

If the endpoint used change to 'https://api.powerbi.com/v1.0/myorg/groups/<group_id>/reports'  then there is no 401 error anymore.

[v-lionel-msft]

Hi @misterwalrus ,

The 401 error means that there is no access permission. I guess it should be a permission problem.

Best regards,
Lionel Chen

If this post helps, then please consider Accept it as the solution to help the other members find it more quickly.

[misterwalrus]

This is very interesting, someone in StackOverflow recommended me to paste the token I got from my script into jwt.io and look at the scp field (scope). It happens that the 'bad' token has the correct scopes,  the 'good' token, the one I got when connecting to powerbi by Connect-PowerBIServiceAccount and use my username/password   has a different scope (user_impersonation)  and a different appid.

I took the appid of the good token and now I am using it, instead of the original application id. It works flawlessly from the python script now.

I suppose this is not the correct solution, and indeed, not the one I was expecting for.  

What is happening to the 'bad' application id? I don't understand it , specially,when the token shows all the correct permissions: 

This is from jwt.io: 

"scp": "App.Read.All Capacity.Read.All Dashboard.Read.All Dataflow.Read.All Dataset.Read.All Gateway.Read.All Report.Read.All StorageAccount.Read.All Tenant.Read.All Workspace.Read.All",