Forum Discussion
Power BI - Snowflake OAuth setup
Hi everyone,
I am working on a Power BI + Snowflake integration setup and would like to confirm whether our understanding of authentication and network access is correct.
Architecture
Snowflake environment is managed by our team.
Power BI tenant belongs to the customer.
Authentication between Power BI and Snowflake is configured using Azure AD External OAuth.
Snowflake configuration includes mapping the Azure identity to a Snowflake service user:
ALTER USER PBI_SVC SET LOGIN_NAME = '[email protected]';
OAuth integration uses the customer Azure Tenant ID:
EXTERNAL_OAUTH_ISSUER = https://sts.windows.net/<Customer-Tenant-ID>/
Authentication Flow (Expected)
User signs in to Power BI using their Azure AD account.
Azure AD authenticates the user.
Azure issues an OAuth token.
Power BI sends the token to Snowflake.
Snowflake validates the token issuer and maps the UPN to the Snowflake user using LOGIN_NAME.
So from our understanding:
Snowflake does not access the customer Azure directory directly
It only validates the OAuth token issued by Azure
Therefore, the only prerequisites from the customer side should be:
Azure Tenant ID
Power BI user email (for Snowflake mapping)
Power BI workspace access
Power BI Pro / Premium license
Network Access Question
Currently our Snowflake endpoint is public, so there are no network restrictions.
However, our platform team mentioned that in production Snowflake may be restricted using network policies.
We understand that scheduled refresh in Power BI Service runs from Microsoft cloud infrastructure.
So if Snowflake network policies are enabled later, would we need to allow Power BI Service outbound IP ranges in Snowflake network policies?
Example scenario:
Development:
Power BI Desktop (Customer VDI)
↓
SnowflakeProduction refresh:
Power BI Service (Microsoft Cloud)
↓
SnowflakeIf Snowflake network policies restrict allowed IPs, would scheduled refresh fail unless Power BI Service IP ranges are allowed?
Main Questions
Is our understanding of the OAuth authentication flow between Power BI and Snowflake correct?
When Snowflake network policies are enabled, do we need to allow Microsoft Power BI Service IP ranges for dataset refresh to work?
Are there any additional prerequisites or best practices we should consider when connecting Power BI (external tenant) to Snowflake using Azure OAuth?
Any guidance from people who have implemented Power BI + Snowflake OAuth with external tenants would be greatly appreciated.
Thanks!
Hi manoj_0911
1. Authentication Flow Validation
Your understanding of the Azure AD External OAuth flow is correct. In this architecture, Snowflake acts as a Resource Server that validates tokens rather than an active client that queries the Azure directory.Mechanism: Snowflake uses the public keys defined in your SECURITY INTEGRATION to verify the digital signature of the incoming OAuth token.
Mapping: The validation relies on matching the upn or email claim within the token to the LOGIN_NAME property of the Snowflake user.
External Tenant Context: Since the Power BI tenant belongs to the customer, they must register the Snowflake Power BI infrastructure as an Enterprise Application in their Azure AD and grant the necessary API permissions (e.g., session:role-any).
2. Network Access & Scheduled Refresh
If Snowflake network policies are enabled, a scheduled refresh in Power BI Service will fail unless specific provisions are made.The Challenge: Power BI Service traffic originates from Microsoft’s shared cloud infrastructure. These outbound IP addresses are dynamic and change frequently.
Requirement: You must add the Power BI Service Tags (or the specific Azure Region IP ranges) to the Snowflake Network Policy ALLOWED_IP_LIST.
Production Best Practice: Relying on public IP whitelisting for cloud services can be management-heavy. For a hardened production environment, consider using an Azure Private Link between the Power BI VNET (via a VNET Gateway) and Snowflake to ensure traffic never touches the public internet.
3. Additional Prerequisites & Best Practices
To ensure a robust implementation across external tenants, consider the following:Audience Claim: Ensure the EXTERNAL_OAUTH_AUDIENCE_LIST in your Snowflake integration matches the Application ID URI configured in the customer’s Azure AD.
Admin Consent: Since this is a cross-tenant setup, a Global Admin from the customer’s Azure AD must grant "Tenant-wide admin consent" to the Snowflake application for the OAuth flow to work for all users.
Role Mapping: If you intend to use specific Snowflake roles, ensure the OAuth token includes the session:role:<role_name> scope; otherwise, the connection will default to the user's DEFAULT_ROLE.
Desktop vs. Service: Remember that Power BI Desktop uses the developer's local network (VDI) to connect, while the Power BI Service uses Microsoft's data center IPs. Both must be accounted for in your network policies.
If this post helps, then please consider Accepting it as the solution to help the other members find it more quickly
3 Replies
Hi manoj_0911
1. Authentication Flow Validation
Your understanding of the Azure AD External OAuth flow is correct. In this architecture, Snowflake acts as a Resource Server that validates tokens rather than an active client that queries the Azure directory.Mechanism: Snowflake uses the public keys defined in your SECURITY INTEGRATION to verify the digital signature of the incoming OAuth token.
Mapping: The validation relies on matching the upn or email claim within the token to the LOGIN_NAME property of the Snowflake user.
External Tenant Context: Since the Power BI tenant belongs to the customer, they must register the Snowflake Power BI infrastructure as an Enterprise Application in their Azure AD and grant the necessary API permissions (e.g., session:role-any).
2. Network Access & Scheduled Refresh
If Snowflake network policies are enabled, a scheduled refresh in Power BI Service will fail unless specific provisions are made.The Challenge: Power BI Service traffic originates from Microsoft’s shared cloud infrastructure. These outbound IP addresses are dynamic and change frequently.
Requirement: You must add the Power BI Service Tags (or the specific Azure Region IP ranges) to the Snowflake Network Policy ALLOWED_IP_LIST.
Production Best Practice: Relying on public IP whitelisting for cloud services can be management-heavy. For a hardened production environment, consider using an Azure Private Link between the Power BI VNET (via a VNET Gateway) and Snowflake to ensure traffic never touches the public internet.
3. Additional Prerequisites & Best Practices
To ensure a robust implementation across external tenants, consider the following:Audience Claim: Ensure the EXTERNAL_OAUTH_AUDIENCE_LIST in your Snowflake integration matches the Application ID URI configured in the customer’s Azure AD.
Admin Consent: Since this is a cross-tenant setup, a Global Admin from the customer’s Azure AD must grant "Tenant-wide admin consent" to the Snowflake application for the OAuth flow to work for all users.
Role Mapping: If you intend to use specific Snowflake roles, ensure the OAuth token includes the session:role:<role_name> scope; otherwise, the connection will default to the user's DEFAULT_ROLE.
Desktop vs. Service: Remember that Power BI Desktop uses the developer's local network (VDI) to connect, while the Power BI Service uses Microsoft's data center IPs. Both must be accounted for in your network policies.
If this post helps, then please consider Accepting it as the solution to help the other members find it more quickly
Hi manoj_0911 ,
I would also take a moment to thank Ritaf1983 , for actively participating in the community forum and for the solutions you’ve been sharing in the community forum. Your contributions make a real difference.
I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions
Hi manoj_0911 ,
I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions.
