How to Use Service Principal in Power BI

Automating your Power BI reports and embedding them into applications can save you massive amounts of time, but it introduces a key challenge: how do you give a script or application secure access without using a real person's login? Using a team member’s credentials is a brittle solution that breaks the moment their password changes. This is where a service principal comes in. This guide will walk you through exactly what a service principal is, why you need one, and how to set it up step-by-step for use with Power BI.

What is a Service Principal (and Why Bother?)

Think of a service principal as a dedicated, non-human user account created specifically for an application, script, or service. In technical terms, it’s an identity within your Azure Active Directory (Azure AD) that isn’t tied to a specific person. Instead of a username and password you’d give to a colleague, a service principal has a Client ID and a Client Secret.

Using a service principal for Power BI administration and embedding isn't just a good idea, it's a best practice for several reasons:

• Secure Automation: Scripts that refresh datasets or manage workspaces can run on a schedule without requiring a user to be actively logged in. This headless authentication is the key to reliable automation that doesn't depend on an individual's account staying active or their password remaining unchanged.
• Granular Security: You can grant a service principal only the specific, narrowly-defined permissions it needs to do its job. This is far more secure than embedding a real user’s credentials into a script, which might give that script overly broad access to all of their content.
• Embedding ("App-Owns-Data"): It’s the standard, recommended method for embedding Power BI content into your own custom applications for external users. This "app-owns-data" model allows your customers to view reports without needing their own Power BI license, because your application is authenticating via the service principal.

Prerequisites: What You’ll Need

Before you get started, make sure you have the following in place. If you don't, you may need to loop in your IT or Azure administrator.

• A Power BI Pro or Premium Per User (PPU) license.
• Administrative permissions in Azure Active Directory (Azure AD) to register an application. This is often restricted, so check with your admin if you can't complete the steps below.
• The ability to enable developer settings in the Power BI Admin portal. You’ll need a Power BI administrator to do this if you aren't one.

Step 1: Create the Azure AD Application

The first step is to register a new application within Azure AD. This process automatically creates both the application identity and the service principal associated with it.

Head over to the Azure portal and follow these steps:

1. Navigate to Azure Active Directory. You can search for it in the top search bar.
2. In the left-hand menu, select App registrations, then click + New registration.
3. Give your application a clear, descriptive name, like PowerBI_Automation_SPN.
4. For "Supported account types," the default option, "Accounts in this organizational directory only," is usually the correct choice.
5. You can leave the "Redirect URI" section blank for this use case. Click Register.

That's it. Your application is now registered in Azure AD.

Step 2: Get Your Credentials (Client ID & Tenant ID)

Once your application is created, you’ll be taken to its overview page. This screen contains two critical pieces of information you need to copy and save somewhere secure (like a password manager):

• Application (client) ID: This is the unique identifier for your application. Think of it as the service principal's "username."
• Directory (tenant) ID: This identifies your organization’s Azure AD instance.

You'll need both of these values to authenticate your scripts and applications.

Step 3: Create a Client Secret

Next, you need to create the service principal's "password," which is called a client secret.

1. In your new app registration's left-hand menu, click on Certificates & secrets.
2. Click the + New client secret button.
3. Give it a brief description (e.g., "PowerShell automation secret") and choose an expiration timeline. Important: Be mindful of this expiration date. Your automation will fail the moment the secret expires, so set a calendar reminder for your team to renew it.
4. Click Add.

This is the most critical part of the process: Immediately after creation, the client secret's value will be displayed on the screen. Copy this value right away and store it securely with your Client ID and Tenant ID. If you navigate away from this page, the value will be permanently masked, and you'll have to create a new one.

Step 4: Enable Service Principal Access in Power BI

Now you need to tell your Power BI tenant that it’s allowed to accept API calls from service principals. This is a crucial security setting that must be enabled by a Power BI administrator.

1. Log in to the Power BI Service (app.powerbi.com).
2. Click the settings gear icon in the top right and go to the Admin portal.
3. Select Tenant settings and scroll down to the Developer settings section.
4. Find the setting titled "Allow service principals to use Power BI APIs" and enable it.
5. For enhanced security, rather than applying this to the entire organization, it’s best practice to apply it to a specific security group. We’ll create that next.

Step 5: Create and Use a Security Group

You don't add service principals directly as users in a Power BI workspace. The correct method is to add the service principal to a security group, and then give that security group access to the workspace.

1. Go back to the Azure portal and navigate to Azure Active Directory.
2. Select Groups from the left menu and click + New group.
3. Set the "Group type" to Security.
4. Give it a descriptive name, like PowerBI_Service_Principal_Admins.
5. Click Create.
6. Once the group is created, find it in the list, open it, and click on Members in the left menu.
7. Click + Add members and search for the service principal you created earlier by its name (e.g., PowerBI_Automation_SPN). Select it and add it to the group.

Remember that security group name. If you enabled the tenant setting for specific security groups in the previous step, be sure to add this new group to that allowlist.

Step 6: Add the Security Group to Your Power BI Workspace

The final configuration step is to grant the security group permissions to the specific Power BI workspace you want to automate.

1. In the Power BI service, navigate to the workspace you want to give access to.
2. Click the Access button at the top of the workspace.
3. In the side panel, type the name of the security group you just created (e.g., PowerBI_Service_Principal_Admins).
4. Assign it a role. To perform most administrative actions via APIs (like refreshing a dataset or modifying content), you'll often need the Admin role. Assign the lowest-privilege role that still allows the service principal to do its job.

With that, your service principal is fully configured and ready to be used.

Putting It to Work: Using Your Service Principal

Here’s a practical example of how you can use these credentials to authenticate in a PowerShell script for Power BI.

First, make sure you have the Microsoft Power BI PowerShell module installed (Install-Module -Name MicrosoftPowerBIMgmt). Then you can use a script like this to connect:

# Store your credentials securely (e.g., in Azure Key Vault for production)
$tenantId = "YOUR_TENANT_ID"
$clientId = "YOUR_CLIENT_ID"
$clientSecret = "YOUR_CLIENT_SECRET"

# Create a PowerShell credential object
$credential = New-Object System.Management.Automation.PSCredential($clientId, (ConvertTo-SecureString $clientSecret -AsPlainText -Force))

# Connect to Power BI using the service principal
Connect-PowerBIServiceAccount -Tenant $tenantId -ServicePrincipal -Credential $credential

# You are now authenticated! Run other commands like refreshing a dataset:
# Invoke-PowerBIRestMethod -Url 'groups/{workspaceId}/datasets/{datasetId}/refreshes' -Method Post

This same authentication concept applies when using Python, C#, or any language that can make REST API calls. You use the Client ID and Secret to request an access token from Azure AD, and then include that token in the header of your calls to the Power BI REST API.

Final Thoughts

Setting up a service principal provides a secure, robust, and professional method for automating your Power BI environment and embedding analytics. It frees you from fragile processes that rely on personal accounts and allows you to build scalable, reliable data workflows.

We know that managing data pipelines and configuring secure access can become a full-time job. At Graphed, we simplify this entire process by turning data analysis into a simple conversation. Instead of writing scripts and configuring enterprise tools, you just connect your marketing and sales platforms in a few clicks, then ask for the exact dashboards you need in plain English. We handle the heavy lifting of connecting, updating, and visualizing your data in real-time, so you can discover insights instead of fighting with setup.