how to effectively determine the token resource URL (sometimes also referred to as audience or scope) for authentication.
introduction.
As we all know, when you want to access something like an Azure SQL Database, you first need to go through an authentication process. You do this by showing a special “digital ID” called access token. To get this token, you usually need to ask a service for it. In the case of Azure, this is Microsoft Entra ID (former Azure Active Directory or Azure AD), the guardian of access to Azure resources. When you ask Microsoft Entra ID for a token, you not only say, “Hey, I’m this program or person, and I need a token,” but you also specify what you want to access – the resource you’re trying to reach. This is where you need to provide the appropriate Resource URL.
Once Microsoft Entra ID verifies your identity and ensures you have the right permissions, it provides you with the token. Now, armed with this token and for the lifetime of that token, you can show it as proof of authentication whenever you want to access the resource. When you authenticate as a personal user, most of what I just described is automatically done for you under the hood.
However, if you want to establish an authentication process programmatically, e.g. when using a service principal, you need to do some of those steps manually. Then, knowing the correct Resource URL is crucial. By the way, I have seen the term Resource URL being used with other names such as Audience or Scope. I believe they are not exactly the same, but I guess sometimes they are used interchangeably. More about Microsoft’s Entra authentication mechanism can be found in the documentation.
Quite a few times, I have been asked for specific Resource URLs. In particular, I have been approached with this question in the context of assigning service principals as owners of Power BI semantic models. In that referred blog post, we transferred the ownership of a semantic model to a service principal, so instead of a user, the service principal handles the authentication process for accessing the data source. In that blog post’s example, our source was an Azure SQL Database. For that purpose, the service principal had to acquire a token with the Resource URL “https://database.windows.net/”.
Sometimes, however, it can be hard to figure out the correct Resource URL for the resource you are trying to authenticate to. Since I couldn’t find detailed documentation, my approach used to be a mix of qualified guesses and “trial & error”. Occasionally, I’ve also been lucky to find hints online, like I did here on stackoverflow.
I gathered, there must be a better way to find the right Resource URL. After all, when authenticating with our own organizational accounts to those data sources, e.g. from Power BI Desktop, under the hood, tokens are fetched, too. So, the correct Resource URL must be used somewhere in that authentication process. We just need to get hold of it.
My first assumption was that those tokens should be cached somewhere locally on my computer. So I tried the following: I authenticated with my own organizational user to a data source in Power BI Desktop and saved the report. I then looked for the token somewhere in my pbip project as well as in the xml files of the User.zip folder. I wasn’t able to find anything useful, and to be honest, I am also kinda glad I didn’t.
My second approach was monitoring the network traffic and intercepting HTTPS requests while authenticating with my user in Power BI Desktop. This method proved successful, and I explain it in more detail it in this blog post. Microsoft suggests to use Fiddler for this purpose of capturing web requests.
Additionally, this article provides a list of Resource URLs for several data sources. Please, feel free to share other Resource URLs or to notify me if any of the ones I’ve listed do not work for you. It’d be also great to let me know if they actually work, so I can mark them as validated or confirmed. Just comment below or shoot me a contact message. A LinkedIn DM works well, too.
prerequisites.
1. Fiddler Classic. You can download it from here.
2. Power BI Desktop
1. What’s the goal?
As outlined in the introduction, the goal is to identify the correct Resource URL needed to retrieve a token for authenticating with a specific data source. In the example below, we wanted to determine the appropriate Resource URL to authenticate with the Management Cost API. This Resource URL would then be utilized to obtain a token, enabling a service principal to authenticate to the Management Cost API from the Power BI Service.
2. A list of data sources and their respective Resource URL
Here is a list of data sources along with their respective Resource URLs. Not all have been verified, yet. I would be super grateful if you could confirm whether they work or not. Additionally, it would be fantastic if you could provide other Resource URLs for data authentication that I can include in the table, allowing others to benefit from our collective effort. Please feel free to comment below or send me a message through the contact form. You can also connect with me on LinkedIn and message me there.
| Data Source | Resource URL | Comment |
|---|---|---|
| Azure Cost Management | https://management.core.windows.net/ | confirmed |
| Azure Data Lake Gen2 | https://storage.azure.com/ | not confirmed yet |
| Azure SQL Database | https://database.windows.net/ | confirmed |
| Azure Synapse Analytics SQL | https://database.windows.net/ | confirmed |
| Azure Resource Graph | https://management.azure.com | not conrimed yet |
| Snowflake | https://analysis.windows.net/powerbi/connector/Snowflake | not cinfirmed yet |
| Fabric Azure Data Explorer (Kusto) | https://kusto.z8.kusto.fabric.microsoft.com | not confirmed yet |
| Fabric Data Warehouse | https://database.windows.net/ | not confirmed yet |
| Power BI Semantic Model | https://analysis.windows.net/powerbi/api | confirmed |
| Amazon Redshift | https://analysis.windows.net/powerbi/connector/AmazonRedshift | not confirmed yet |
| Google Big Query (Beta EntraID) | https://analysis.windows.net/powerbi/connector/GoogleBigQuery | not confirmed yet |
| Azure Databricks | https://analysis.windows.net/powerbi/connector/AzureDatabricks | not confirmed yet |
| Dataflows | https://powerquery.microsoft.com/ https://service.powerapps.com/ |
not confirmed yet |
| Azure Key Vault | https://vault.azure.net/ | not confirmed yet + not possible to connect from Power BI |
| Azure Purview | https://purview.azure.net/ | not confirmed yet + not possible to connect from Power BI |
3. A way on finding those Resource URLs yourself.
If you were unable to locate the correct Resource URL in the table above, I can guide you on how to obtain those URLs on your own. The method involves capturing the HTTP and HTTPS requests in your network as you authenticate on your device to your data source – in our case from Power BI. For this purpose, we utilize Fiddler, a web debugging proxy tool that allows developers to inspect network traffic. It supports a variety of protocols and offers features like traffic recording, playback, and HTTP request composition..
For us to be able to investigate the HTTPS requests, we need to enable HTTPS decryption. For this double-click on an HTTP request on the left; in our example, we used www.tackytech.blog. A new pane will open on the right. To activate HTTPS decryption, click on the yellow button. Microsoft has also listed the required steps to do this.
Note: Be aware that installing the root certificate is done at your own risk. While it may appear safe, there could be implications. You are, after all, installing a root certificate on your device. For a brief summary by ChatGPT on this matter, see Appendix I. Additionally, Appendix II outlines the steps to remove the certificate once you have finished debugging your traffic.
Here the SCARY TEXT AHEAD message that pops ups, when enabling HTTPs decryption:
After enabling decryption, you should be able to observe HTTPS requests being tracked by Fiddler. Next, we start the authentication process to a data source from inside Power BI Desktop (of course, you could use other tools, too). Interestingly, for some connections, the actual existence of the data source is not necessary. For us, it doesn’t matter whether authentication and authorization are successful either way. Instead, we aim to discover how Power BI operates internally to obtain a token for authentication to that specific type of data source. In this instance, as we focus on an Azure SQL Database, we select Get Data, search for Azure SQL Database, and click Connect.
Next, we input the connection details. With some data sources you actually need to provide proper connection details, otherwise the authentication process stops before any HTTPS requests are sent. In the case of an Azure SQL Database, you can fill in anything, though:
We’re almost there! Select Microsoft Account (which may also be referred to as Organizational Account, Azure Active Directory, or Microsoft Entra ID). Upon signing in, a new window will appear where you should enter your account details.
At this point, we must return to Fiddler. Locate the row that contains the host login.windows.net with the URL common/oauth2/token, or something similar. On the right-hand side, select TextView in the lower box. Within the text, you should identify the Resource URL. For instance, in our scenario, it is indeed https://database.windows.net/.