REST API Bearer Token security (3rd party developer)

[cwisoff]

Hi, I'm a software developer building an app for a customer. Our customer wants to use Power BI to securely access some of the data we store for them in our database. Our current plan is to expose a single endpoint for them that allows for a data dump of specific resources. Our customer would like to be able to ping this endpoint multiple times a day to update the data that generates reports for them. We'd like to issue our customer a Bearer Token that they can put in in PowerBI, but we have some security concerns that we need to address first:

1. If we issue our user a Bearer Token and they enter it into PowerBI, what security measures does PowerBI have in place? Will the token be stored or cached on our user's desktop (less secure) or will it be stored in Microsoft servers and only be retrieved as needed? When Power BI pings our endpoint will that happend directly from our customer's desktop client (less secure) or will Microsoft servers ping our API and then send the data to our customer's desktop?

2. If PowerBI does store and utilize bearer tokens directly from the desktop client, what other security measures does PowerBI support? If we were to rotate/refresh our tokens, would our customer have to manually update the token in powerBI or is there an automated way for PowerBI to refresh tokens?

[v-agajavelly]

Hi @cwisoff ,

Did you get a chance to try setting up the OAuth2 flow with the SDK samples yet, or are you still experimenting with other approaches?. 

Regards,
Akhil.

[cwisoff]

We are going to start by just implementing a long-lived bearer token. We're a small startup and the data we're exposing isn't very sensitive (i.e. no PII). This will unblock some other work. We're looking to implement Oauth in the next couple of months.

[v-agajavelly]

Hi @cwisoff ,

Thanks @VahidDM for the detailed breakdown, that really cleared things up. The OAuth2 route definitely seems like the more secure way forward. For anyone else starting out, the most reliable docs are.

• Power Query SDK - Visual Studio Marketplace  build a custom connector with OAuth2.
• The authentication API in Power BI custom visuals - Power BI | Microsoft Learn  explains Desktop vs Service behavior.
• Handling authentication for Power Query connectors - Power Query | Microsoft Learn

The Crossjoin blog post OP found is also helpful, but Microsoft’s docs are the definitive source. Beginning with the SDK samples is usually the smoothest way to see how refresh tokens and automatic refresh work end-to-end.

Regards,
Akhil.

[VahidDM]

Hi @cwisoff 

Here’s the practical, security-focused view:

1. Where is the token stored / who calls your API?

• Power BI Desktop: Calls go from the user’s machine directly to your API. The credential (if entered through Data Source Settings) is stored locally, encrypted (Windows Credential Manager). If a developer hard-codes a token in M (Web.Contents headers/parameters), that token is saved inside the PBIX — don’t do this.

• Power BI Service: Scheduled refresh calls originate from Microsoft datacenters (or from an on-premises gateway if configured). Dataset credentials are stored encrypted at rest in the Service and used by the refresh infrastructure.

2. Token rotation / auto-refresh

• If you use a static Bearer token (“API key in header”), there’s no automatic refresh: when you rotate it, the customer must update the dataset credentials (Service) or Desktop data source settings.

• If you want automatic refresh/rotation, implement OAuth 2.0 (authorization code + refresh token) and expose a proper token endpoint. In Power BI:

  • Best: provide a custom connector (Power Query connector) using OAuth2; Power BI will use the refresh token to obtain new access tokens during refresh.

  • Avoid embedding tokens in query code. Keep tokens only in the credential store.

• Optional hardening: front your API with Azure API Management, use per-tenant audience/scopes, short-lived access tokens, IP allow-listing for Service regions (or require gateway), and consider Azure Key Vault + parameters (for non-OAuth secrets that must be rotated by ops).

Recommendation: Don’t issue a long-lived static bearer token. Offer OAuth2 with refresh tokens and a custom connector so Power BI Service can refresh safely without user intervention.

[cwisoff]

Thanks! This is very helpful @VahidDM . We didn't realize you could do OAuth in the context of PowerBI, but that definitely seems like the better/more secure approach. Do you have any suggestions about documentation/tutorials we could follow for implementing? Our team is pretty new to PowerBI, so we're still learning its ins and outs. I found this article: https://blog.crossjoin.co.uk/2021/08/29/connecting-to-rest-apis-with-oauth2-authentication-in-power-...which links to some promising documentation, but as the article mentions there seems to be a lot of conflicting information about implementing OAuth in PowerBI. Searching the community forums, I found at few posts that said OAuth wasn't even available. If you know of any definitive documentation or support resources that would help us avoid going down paths we shouldn't.