## Snowflake-specific guidance

Snowflake auth contains **intentional stubbing behavior** that must not be removed or “cleaned up”.

### Stubbed password behavior

Some Snowflake authentication methods **must provide a password to the downstream builder even when the authentication method does not actually use one**.

To support this, the code intentionally injects a stub password:

`ADBC_STUB_PASSWORD`

This occurs in flows such as:

- keypair authentication
- SSO (`externalbrowser`)
- other flows where the builder still expects a username/password shape

This stub exists to satisfy downstream driver expectations while preserving correct auth semantics.

Understand that each of these is a potentially semantically critical choice:

- removing the stubbed password
- replacing it with an empty value
- attempting to "simplify" the logic by omitting the password
- stubbing different auth flows that are in fact accept either a user-provided value or nothing

Removing or altering this behavior can break valid Snowflake authentication flows.

### OAuth exception

Unlike other auth methods, **OAuth does NOT use the stubbed user or password**.

OAuth flows intentionally avoid injecting username/password credentials and instead pass the OAuth credentials directly.

Do not introduce stubbed credentials into OAuth flows.

### Why this matters

If the stub logic is modified incorrectly, the result may:

- break authentication for existing Snowflake profiles
- prevent users from overriding credentials correctly
- cause the driver builder to reject valid configurations

These failures typically appear **only at runtime**, not at compile time.

### Human verification required

Any change affecting:

- `ADBC_STUB_PASSWORD`
- password handling in Snowflake auth flows
- OAuth credential handling
- username/password injection logic

must be explicitly flagged for **human verification before commit**.