Power BI Advanced Series · Power BI Embedding & Security · by Raushan Ranjan, MCT
Quick Answer
App-owns-data embedding is a Power BI embedding pattern where your application authenticates with a service principal, obtains an embed token, and renders Power BI content in an iframe. End users do NOT need Power BI licenses — the application owns the license. This is the standard model for ISVs and customer-facing analytics portals.
Embedding Power BI reports into your application can transform a static user experience into a data-driven, interactive one. The "App Owns Data" model is a powerful way to do this, especially if you want to share a single report with many users who don't have Power BI licenses. Let's break down the key concepts and architecture behind this model.
1. Introduction: What is Power BI Embedding?
Power BI embedding is the process of displaying Power BI reports directly inside your own application, bypassing the need for users to navigate to the Power BI service. There are two primary embedding models:
| Model | Description | Analogy |
|---|---|---|
| User Owns Data | Each user logs in with their own Power BI account. Access is based on their individual permissions. | Like giving every person a key to a private dashboard room. |
| App Owns Data | Your application, not the end user, holds a Power BI service account. Users do not need individual Power BI accounts. | Like a public dashboard in a hotel lobby—any guest can see it without their own key. |
In this guide, we'll focus on the App Owns Data model, which is perfect for SaaS applications, internal dashboards for employees, and other scenarios where you need to share analytics broadly without managing individual licenses.
2. Key Components of App Owns Data
To successfully embed a report, you must first understand these essential components that work together behind the scenes.
a) Azure AD App Registration
Your application needs its own identity to interact with the Power BI service. You create this identity by registering the app in Azure Active Directory (AAD). This creates a Service Principal, which acts as a non-human identity for your application.
- Client ID: The unique identifier for your app.
- Client Secret: The password for your app's identity. Keep this secure!
- Tenant ID: The unique identifier for your Azure AD tenant.
Analogy: This is like giving your app a special ID card to enter the Power BI “building.”
b) Power BI Workspace & Reports
Power BI reports are organized and stored in workspaces. Your registered app (the Service Principal) must be granted access to the workspace that contains the reports you want to embed. This is typically done by giving it a role like Admin or Member.
Analogy: Think of the workspace as a room where dashboards are stored. The app’s ID card (Service Principal) must have access to that room to show the dashboards to your users.
c) Authentication & Access Token
To prove its identity, your app authenticates with Azure AD using its Client ID, Secret, and Tenant ID. Azure AD then issues an Access Token. This token is a credential that proves the app has permission to call Power BI APIs.
Analogy: This token is like a temporary guest pass for the Power BI building. It has an expiration time (usually 1 hour), so your app must be able to request a new one when the old one expires.
d) Embed Token
The Embed Token is a critical piece for displaying the report in your application. Unlike the access token, which is for the app's use with the Power BI API, the embed token is for the front-end to render a specific report. It is generated by your backend using the Power BI REST API and is sent to the client. This token is what the Power BI JavaScript SDK uses to load the report.
Analogy: The embed token is like a specific ticket to watch a particular dashboard in the lobby. Without it, the dashboard won’t load.
e) Row-Level Security (RLS)
Row-Level Security (RLS) is a powerful feature that restricts the data a user can see in a report based on rules you define. In the App Owns Data model, this is essential for multi-tenant applications to ensure each customer only sees their own data. The RLS rules are applied when the embed token is generated.
Analogy: Everyone can enter the lobby, but only people from the "red team" can see the "red-floor" dashboards.
3. Architecture Overview
The process of embedding a report is a sequence of secure calls between your application, Azure AD, and the Power BI service. Here's the high-level flow:
- Your backend application requests an access token from Azure AD using its Client ID and Secret.
- Azure AD validates the credentials and returns the access token.
- Your app's backend calls the Power BI REST API (using the access token) to request an embed token for the specific report you want to display.
- The Power BI REST API generates the embed token and sends it back to your backend.
- Your backend sends the embed token and the report's URL to the front-end (web page).
- The Power BI JavaScript SDK on the front-end uses the embed token and URL to securely load and display the report in the browser.
Simplified Flow:
`User` → `Your Frontend` → `Your App Backend` → `Azure AD` → `Power BI REST API` → `Embed Token` → `Report`
4. How Filters Work in Embedded Reports
Even with the "App Owns Data" model, you can provide dynamic user-driven filtering. Using the Power BI JavaScript SDK, you can apply filters programmatically to the embedded report. For example, your app could have a dropdown for "Region," and selecting a value would send a filter command to the report to show data only for that region.
Analogy: The app is like a concierge: it knows which floors (filters) the guest wants to see and updates the dashboard accordingly.
5. Common Use Cases for App Owns Data
| Use Case | Example |
|---|---|
| SaaS Analytics | A company offers dashboards to clients without requiring Power BI accounts. |
| Internal Dashboards | Employees see sales reports in an internal portal without each needing a Power BI Pro license. |
| Embedded Portal | A SharePoint or custom web app showing interactive, real-time reports. |
6. Best Practices
- Security First: Never hardcode secrets in your code. Use secure storage like Azure Key Vault.
- Principle of Least Privilege: Grant your Azure AD app only the minimum permissions required to access the necessary workspaces and reports.
- Handle Token Expiry: Both access tokens and embed tokens expire. Your application must have logic to detect this and refresh them dynamically to ensure a smooth user experience.
- Enforce Security: Even with "App Owns Data", use RLS to secure data access, especially for multi-tenant scenarios.
- Monitor and Log: Implement robust error handling and logging to track token generation failures and other API exceptions.
7. Summary
The App Owns Data model is a powerful and flexible way to integrate Power BI into your applications, allowing you to serve reports without requiring your end users to have individual Power BI licenses. It relies on a well-defined process involving Azure AD for authentication, the Power BI REST API for generating tokens, and the Power BI JavaScript SDK for rendering the report.
By understanding these components and the secure architecture, you've laid a strong foundation for the next step—a hands-on implementation, which we will cover in our next blog.
Quick Knowledge Check
Q1. What is the key difference between the app-owns-data and user-owns-data embedding scenarios in Power BI?
Show Answer
In app-owns-data, the application authenticates with Azure AD using its own identity (service principal or master user) and generates embed tokens for anonymous or external users — no Power BI licence is required per end user. In user-owns-data, each end user signs in with their own Azure AD account, and their Power BI licence and permissions control what they can view. App-owns-data is used for embedding in public-facing or multi-tenant SaaS applications (ISV scenario). User-owns-data is used for internal corporate portals where all users have Power BI accounts.
Q2. In app-owns-data embedding, what does an embed token grant, and what are its two main properties?
- A) A permanent OAuth token that grants full admin access to the Power BI tenant
- B) A short-lived token (typically 1 hour) that authorises a specific report/dashboard to be embedded for a specific audience, with optional RLS effective identity
- C) A token that replaces the user's Power BI Pro licence for 30 days
- D) A token generated client-side from the Power BI JavaScript SDK
Show Answer
B. An embed token is a short-lived JWT (typically 1 hour by default, configurable up to several hours) generated by the Power BI REST API. It specifies: (1) what is being embedded (report, dashboard, or tile ID and workspace); (2) access level (view or edit); and optionally (3) an effective identity for row-level security to restrict data to a specific user or tenant. It is generated server-side — never in client JavaScript.
Q3. Why must embed token generation happen server-side in your backend API, not in client-side JavaScript?
Show Answer
The token generation requires the service principal's client secret (or master user's password) to authenticate with Azure AD. Exposing these credentials in client-side JavaScript allows any user to read them from the browser and generate unlimited embed tokens, effectively bypassing all access controls. The backend API authenticates with Azure AD, generates the embed token, and sends only the token to the client. The client uses the token to load the report but never has access to the underlying Azure AD credentials.
5 Things to Remember
- App-owns-data = no Power BI licence per user — the app authenticates once; embed tokens grant view access to external users. Ideal for ISV/SaaS embedding.
- Embed tokens are short-lived — default 1 hour. Implement token refresh logic in your app to avoid expired token errors on long sessions.
- Token generation must be server-side — never expose service principal secrets or master user credentials to client JavaScript. Generate tokens in your backend API only.
- Use service principal, not master user — service principals don't expire passwords, support MFA bypass for automation, and are easier to manage in CI/CD pipelines.
- Power BI JavaScript SDK renders the embedded report — the client calls
powerbi.embed(container, config) with the embed token and embed URL to display the report inside a div.
Quick Knowledge Check
Q1. What is the key difference between the app-owns-data and user-owns-data embedding scenarios in Power BI?
Show Answer
In app-owns-data, the application authenticates with Azure AD using its own identity (service principal or master user) and generates embed tokens for anonymous or external users — no Power BI licence is required per end user. In user-owns-data, each end user signs in with their own Azure AD account, and their Power BI licence and permissions control what they can view. App-owns-data is used for embedding in public-facing or multi-tenant SaaS applications (ISV scenario). User-owns-data is used for internal corporate portals where all users have Power BI accounts.
Q2. In app-owns-data embedding, what does an embed token grant, and what are its two main properties?
- A) A permanent OAuth token that grants full admin access to the Power BI tenant
- B) A short-lived token (typically 1 hour) that authorises a specific report/dashboard to be embedded for a specific audience, with optional RLS effective identity
- C) A token that replaces the user's Power BI Pro licence for 30 days
- D) A token generated client-side from the Power BI JavaScript SDK
Show Answer
B. An embed token is a short-lived JWT (typically 1 hour by default, configurable up to several hours) generated by the Power BI REST API. It specifies: (1) what is being embedded (report, dashboard, or tile ID and workspace); (2) access level (view or edit); and optionally (3) an effective identity for row-level security to restrict data to a specific user or tenant. It is generated server-side — never in client JavaScript.
Q3. Why must embed token generation happen server-side in your backend API, not in client-side JavaScript?
Show Answer
The token generation requires the service principal's client secret (or master user's password) to authenticate with Azure AD. Exposing these credentials in client-side JavaScript allows any user to read them from the browser and generate unlimited embed tokens, effectively bypassing all access controls. The backend API authenticates with Azure AD, generates the embed token, and sends only the token to the client. The client uses the token to load the report but never has access to the underlying Azure AD credentials.
- App-owns-data = no Power BI licence per user — the app authenticates once; embed tokens grant view access to external users. Ideal for ISV/SaaS embedding.
- Embed tokens are short-lived — default 1 hour. Implement token refresh logic in your app to avoid expired token errors on long sessions.
- Token generation must be server-side — never expose service principal secrets or master user credentials to client JavaScript. Generate tokens in your backend API only.
- Use service principal, not master user — service principals don't expire passwords, support MFA bypass for automation, and are easier to manage in CI/CD pipelines.
- Power BI JavaScript SDK renders the embedded report — the client calls
powerbi.embed(container, config)with the embed token and embed URL to display the report inside a div.