Skepticism about U2M OAuth: Does Snowflake Federation Actually Switch User Identity per Query?

[martkev]

Hi everyone,

I'm currently setting up Snowflake federation with Databricks using Microsoft Entra ID (U2M OAuth). However, I'm skeptical that the connection truly switches the user identity dynamically for each Databricks user (https://docs.databricks.com/aws/en/query-federation/snowflake-entra).

Since the connection requires a static Snowflake username during setup, it seems that all queries might still run under this single identity rather than the identity of the logged-in Databricks user.

Can someone confirm whether Snowflake federation actually propagates per-user identity at query time, or if the connection always uses the initially configured user?

Thanks!

[Raman_Unifeye]

In theory, the User-to-Machine (U2M) OAuth flow you are setting up with Microsoft Entra ID is designed to propagate the per-user identity dynamically at query time. I haven't set it up myself though.

[martkev]

So why do you have to set a username in the unity catalog connection then (see image.png attachment)? This would make no sense and I highly assume the user identity will stay static. Anyone tried it before?

[mark_ott]

Snowflake federation with Databricks using Microsoft Entra ID (U2M OAuth) is intended to support per-user identity propagation—that is, each Databricks user is supposed to have queries executed under their own Snowflake identity at query time, rather than a static, system-level account. The design of Snowflake federation using Entra ID with the U2M OAuth flow specifically enables Databricks to obtain a user-specific OAuth token from Entra ID, which is then mapped to the appropriate Snowflake user.​

However, confusion often arises because setting up this integration sometimes requires specifying a static Snowflake user in certain configuration steps (such as for token verification or as part of legacy connection settings). In practice, for true U2M (User-to-Machine) federation, the OAuth access token Databricks obtains from Entra ID includes identity claims for the logged-in Databricks user. Snowflake validates this token and, based on mapping settings (like email, login_name, or a custom claim), associates the session with the matching Snowflake user.​

If the connection uses the U2M (user-based) OAuth flow and the mapping is correctly configured, queries will indeed run as the logged-in Databricks user's Snowflake identity. If it's set up incorrectly (or uses a machine-to-machine OAuth flow), all queries will execute under the service (static) account. It is important to confirm that:

• The Databricks-Snowflake federation setup explicitly uses the "on behalf of user" (U2M) OAuth flow.​

• The token mapping and user provisioning between Entra ID and Snowflake are correctly in place (SCIM or similar mapping).​

If you see required fields in the Databricks configuration for a static Snowflake username, this might only be to allow Databricks to bootstrap initial token validation and not for actual per-query execution. In modern, user-federated configurations, Snowflake will execute the query under the identity from the Entra-provided OAuth token representing the active Databricks user.​

Key Takeaway

• If U2M OAuth is correctly configured in both Databricks and Snowflake, queries should execute as the individual Databricks user mapped into Snowflake, not a fixed account.​

• If there is static user configuration in the connection, double-check that it's not being used for actual query executions, or re-examine documentation and test with multiple users to confirm real user propagation.​

This approach ensures per-user auditability, granular permissions, and alignment with security best practices for enterprise data systems federation.