Acquire access token from Azure AD for native app registration (PowerBI) using client credentials

Question

I am using adal4j (version 1.2.0) from a backend application to acquire an access token to be able to use the PowerBI REST APIs to embed reports (more specifically, the GenerateToken method). I have registered a native app in Azure, and provided it the necessary permissions. I can acquire an access token using a username/password combination as follows:

AuthenticationContext ac = new AuthenticationContext("https://login.windows.net/TENANT_ID/oauth2/authorize", false, es);
Future<AuthenticationResult> f = ac.acquireToken("https://analysis.windows.net/powerbi/api", CLIENT_ID, USERNAME, PASSWORD, null);

And then use the token to authenticate to the APIs successfully, and ultimately show the embedded report. However, I my case, I would like to of course use the client credentials (client ID, client secret) instead of a user account. I can acquire the token again as follows:

AuthenticationContext("https://login.windows.net/TENANT_ID/oauth2/authorize", false, es);
ClientCredential cc = new ClientCredential(CLIENT_ID, CLIENT_SECRET);
Future<AuthenticationResult> f = ac.acquireToken("https://analysis.windows.net/powerbi/api", cc,null);

The client ID is the application ID of the registered native app, and the client secret is defined by adding a key to the application. Again, I get the token, but now I am not able to use it to authenticate against the APIs anymore (HTTP 403, without any further details).

So my question is, that is this a valid scenario that should work in the first place, and/or am I just missing a piece of technical information either in Azure or using adal4j?

Edit: Below is a screenshot of the delegated app permissions.

Saimon

Did you check the token that you get? You can use sites like jwt.io to inspect their contents. But unless it has changed from when I previously worked with it, the PBI REST API only allowed delegated calls. Which means you must run them in the context of a user. – Winona

@Winona Thanks for the tip. I already checked that the token type and expiration are ok from the authentication result, and jwt.io shows both tokens to be valid. The one generated with a username/password combination has much more information in the payload though, specifically relating to the user account. This probably supports your claim of only delegated calls being allowed. Will have to try to get a quote on this, but if it is true, I guess the option is to create a dedicated account with a never expiring password, which is a bit disappointing. – Saimon

The token should contain roles if the app-only authentication results in some roles given for the app (also called app permissions). In delegated calls there are "scopes" in the token (the scp claim). – Winona

It might actually be a licensing problem if I happen to be correct. Since every user of Power BI requires some license, it would be a bit problematic if you could define an app with full access to every user's workspace, essentially bypassing all license requirements for it. – Winona

@Winona Ok, I can confirm the scopes with the username-based token, but can't find roles in the client-based token (although they are defined in the app registration). As for licensing, I believe we are entering a capacity-based model, just announced in the beginning of the month. – Saimon

Right, that's true. Could you add a screenshot of the permissions that are defined for the app? – Winona

Just added a screenshot of the delegated permissions. – Saimon

Those are all delegated permissions and thus require user context. You can't call the API with client credentials. – Winona

Answer 1

AFAIK , Power BI REST API only supports delegated permissions but does not support any application permissions . You will find no application permission available in azure portal . So Power BI REST API doesn't allow client credential flow without user identity . Related threads here and here are for your reference .

If you want to connect to Power BI REST API from a Service , you could use Resource Owner Password Credentials Grant flow .

Liam

Yeah, the password grant is the only one that allows unattended calls. But OP has to be sure the password doesn't expire and that there is no MFA etc. – Winona

Ok, thanks, I think my original question about the valid scenario is answered. – Saimon

Yes, as @Winona said , resource owner flow has some limitations , you could refer to this blog for more details . – Liam