Summary
Customers using Snowflake OAuth with dbt Fusion experienced two distinct authentication failures after a release change. For the first phase of this incident, configurations that included a user field (commonly present in existing profiles) began to be considered erroneous, resulting in an error message stating Snowflake OAuth “does not support user.”
After initial mitigation of this first phase, a smaller subset of dbt users experienced a second error, indicating the authenticated username did not match the username tied to the OAuth access token. The mitigation for this second error was identified as mismatch that internally stubbed value that should have been left None.
Impact
Affected dbt accounts were unable to successfully authenticate to Snowflake using OAuth in impacted environments, resulting in failed runs and connection errors.
Impact was limited to specific Environments utilizing dbt Fusion, that were also utilizing Snowflake OAuth configurations with specific profile patterns (including user, and later, token/user mismatch scenarios).
Root Cause
Phase 1: “OAuth does not support user”:
A change was released that tightened profile validation for Snowflake OAuth which treated certain fields (including user and password) as hard errors instead of warnings. While those fields are not required for Snowflake OAuth, many existing customer configurations included them, so the stricter validation caused previously working configs to fail. While this was the intended behavior, dbt had intended the released version to only throw a warning, rather than the hard error.
Mitigation: dbt pushed a new release so as to correct those fields to no longer result in hard-failure for OAuth configurations (returning to a warnings/compatibility approach).
Phase 2: Token username mismatch (Snowflake 390309) error:
After the Phase 1 release was live, a second separate issue was identified in the OAuth flow where dbt Fusion was supplying a stub/dummy user value internally. While Snowflake does look for stub values for keypair, sso, and other auth methods; in this instance, this field has specific override logic of what user is tied to refresh/access token within dbt. Which caused an error when the stub value did not match the Snowflake token owner.
Fix: A second release was tested and validated that updated Fusion to stop injecting a user value for OAuth, unless the customer explicitly sets this within their configuration.
