A company can have its Power BI reports ready for customers and still get stuck at the login screen. When the IT team uses Microsoft Entra ID, keeping the same sign-in method seems like the obvious choice. Then a customer asks to use Okta, while another wants its staff to sign in without creating new Microsoft accounts. The reports haven't changed, but the way people reach them now needs another look.
With Power BI Embedded, the application and the person viewing a report have separate identities. Your application connects to Power BI through a service principal or a master user account. Customers sign in to the application through the method you choose. If it sends the wrong customer details to Power BI, a successful login can still expose another company's figures.
Why Identity Choice Isn't a Power BI Licensing Decision
In Microsoft's app-owned data model, your application gets permission to show Power BI content through an embedding identity. A service principal is the usual choice for a production application. A master user account can also work, but it needs a suitable Power BI user license and workspace access. Microsoft explains these requirements in its guidance for embedding reports for customers.
That account does not decide how your customers sign in. One customer might use Entra ID at work, while another uses Auth0. Neither person needs a separate Power BI account under the app-owns-data setup. The application handles login and requests an embed token for the content they can see.
Power BI capacity and Power BI licensing rules still apply, regardless of the customer login provider. An identity service may have its own charges, but choosing Okta over Entra ID does not change the basic Power BI embedding model. The harder question is how the application connects each signed-in customer to the correct report access.
Four Identity Options for External Analytics
The best choice depends on the customers who will use the dashboards. A small group of partners may already have Microsoft work accounts, while a customer portal open to many companies needs to accept more kinds of sign-in. These two cases can require very different setups.
None of these options changes the report itself. They control how someone gets into the portal before Power BI receives an embed request. OpenID Connect is a sign-in standard, while Auth0 is a product that supports it. A portal can accept multiple providers, but it must still know which customer each account belongs to.
Login security deserves attention here. Even a well-protected report can be exposed when the application lets the wrong person sign in.
Matching the Identity Provider to Your Customers
When Microsoft Entra ID Is Enough
Entra ID is a practical choice when your customers already use Microsoft accounts and your application can support their sign-in setup. Their IT teams may already have policies covering access to business applications. You still need to configure the app so those users can sign in through the right tenant. Using Entra internally doesn't automatically mean every outside organization can open the portal.
For a company serving a few known business customers, this may save its team from managing another set of passwords. New users can get access through the customer's existing account process. The report permissions still belong to the application, not the sign-in screen.
When Entra ID B2B Makes Sense
Entra ID B2B is built for working with people outside your organization. A partner employee can use an existing account while being represented as a guest in your tenant. Your team then controls that guest's access to the application. Microsoft's B2B documentation also covers guest invitations and access settings.
This works well when named partner users need access over time. It can support large groups, too, but managing many guest accounts adds work unless you plan onboarding and removal carefully. If a partner employee leaves, the application should no longer accept that person's access. Also review guest access when a customer contract ends.
When Okta or Auth0 Fits Better
A customer with Okta already in place may not want another sign-in process for its staff. Connecting the portal to that customer's identity service lets its IT team keep using familiar account controls. The application receives the signed-in user's details and decides which Power BI content they can access. Those details still need to map correctly before it creates an embed token.
Auth0 or another OIDC provider can be a good fit when your customers use different identity systems. One customer may bring a corporate account, while another needs a different sign-in option. The application can support multiple providers, but it doesn't get a common set of user claims for free. That difference becomes important when report access depends on company membership.
How Identity Choice Affects Power BI Row-Level Security
The Account That Embeds the Report Isn't the Viewer
Imagine two customers opening the same sales report through your portal. Both reports load through the application's embedding identity, but each customer should see different rows. Power BI won't know which customer signed in unless the application passes the correct user context to the report. For models using row-level security, that usually means setting the effective identity and appropriate roles when creating the embed token.
The risk sits in the mapping between the signed-in account and the Power BI model. If the application maps a user to the wrong customer ID, a working login can still return the wrong data. If it fails to assign a valid identity, the viewer may see an empty report or an error instead. Testing a successful sign-in alone won't catch either problem.
When Claims Don't Match the RLS Rules
Identity providers don't all return user details in the same shape. Your Entra setup might use a group claim to identify a customer, while an Auth0 connection sends that information in another field. Code written for the first format won't necessarily recognize the second one. The mistake may stay hidden until that customer opens its first report.
Multifactor authentication belongs in this plan as well. Microsoft's 2025 Digital Defense Report recommends phishing-resistant MFA to reduce account takeovers. The customer's identity provider can set the exact policy, but the application must know which sign-ins meet its access rules.
What Happens When You Add AI Answers to Embedded Reports?
A customer might first open a Power BI dashboard and later ask an AI assistant about the same sales figures. That new way of getting an answer shouldn't let the customer reach data hidden from the report. The assistant needs the same customer context when it reads protected information. Otherwise, a correctly filtered dashboard can sit beside an AI feature with broader access.
The shared sign-in method gives the application a starting point, but report rules don't automatically carry over to every AI feature. The AI service must apply the intended user permissions when it retrieves data. The team also needs a record of which user asked for the answer and what information was accessed. If the AI feature runs under a shared service account, it must still connect each question to the right customer.
A Practical Evaluation Checklist
Before choosing a provider, the team needs a clear picture of who will use the portal. A sign-in method that works for the first customer may become hard to manage after more organizations join. Testing with actual customer accounts is more revealing than comparing feature pages.
This is also where the delivery platform makes a difference. Reporting Hub documents support for Entra ID B2B, Okta, Auth0, and other OpenID Connect providers. Teams can use a trial environment to check the sign-in flow against their own Power BI access rules. They still need to verify the user mapping for each provider they plan to use.
Frequently Asked Questions
Does My Identity Provider Change Power BI Licensing Costs?
The login provider doesn't change how customers embed Power BI content. Your application still needs the right embedding setup and report capacity. Okta or Auth0 may have their own pricing, so the full sign-in setup cost can change even if Power BI costs don't.
Can I Change Identity Providers After Launch?
Yes, but the work depends on how the application handles user identities. A portal with a separate mapping from login claims to customer records may need fewer changes. Hardcoded group names or provider-specific fields take more work to replace, especially when they control report access.
Is Microsoft Entra ID Required for Embedded Power BI?
Entra ID supports the application's authentication to Power BI through its embedding identity. Customers using an app-owns-data portal don't have to sign in with Entra themselves. The portal can accept another supported login method and then request the Power BI content on their behalf.
Does Row-Level Security Change With the Provider?
The Power BI RLS rules stay in the semantic model. What changes is the user information the application receives at sign-in and how it maps that information to the effective identity used for embedding. A provider change requires a new set of report access tests.
Should I Use Entra ID B2B, Okta, or Auth0 for External Users?
Entra ID B2B is well suited to guest access managed through your tenant. Okta may suit customers whose employees already sign in through an Okta-managed account. Auth0 or another OIDC connection can help a portal accept several sign-in setups, provided the application handles each provider's claims correctly.