Forum Discussion
REST API Bearer Token security (3rd party developer)
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.
Hi cwisoff
Here’s the practical, security-focused view:
-
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.
-
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.
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-query-power-bi/ 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.