SNOW-1964017: Option to encrypt the temporary credential set during external browser auth

[jsnb-devoted]

What is the current behavior?

I'm looking to move our cli based authentication to external browser sso and client side caching via allow_id_token. Right now the credential is stored unencrypted on disk via the TEMPORARY_CREDENTIAL_FILE variable.

What is the desired behavior?

My team has questions around how secure it is to store that file unencrypted. If compromised -- could that credential could be used by a bad actor to gain access to our Snowflake account?

Is there a potential path to providing a key to encrypt the temporary credential file so it can't be read in plain text?

How would this improve snowflake-connector-python?

This would make the SSO authentication more secure

References and other background

Is this potentially calling out the same issue?
https://advisories.gitlab.com/pkg/maven/net.snowflake/snowflake-jdbc/CVE-2025-24790/

[sfc-gh-sghosh]

Hello @jsnb-devoted ,

Could you let us know how you configuring the connections ? Please share the code snippet for the connections you trying via python connector.

Are you using MFA and then trying to set authenticator=externalbrowser ?

If yes, at present this combination is not supported, as it will throw error such as There was an error related to the SAML Identity Provider account parameter

Regards,
sujan

[jsnb-devoted]

@sfc-gh-sghosh We are primarily looking to connect via the dbt-core package (docs) on a remote machine. I think that more or less amounts to connecting like this:

import os
import snowflake.connector
from snowflake.connector.errors import OperationalError

try:
    conn = snowflake.connector.connect(
        account="xxx.xxxxxx.aws",
        authenticator="externalbrowser",
        warehouse="XXXXXX",
        database=f'xxxxx',
        schema="xxxx",
        user="xxxxx",
    )
    print("Successfully connected to Snowflake using SSO")
except OperationalError as e:
    print(f"Failed to connect to Snowflake: {e}")

dbt has it set up such that opening the browser fails because the server has no browser so then it prompts us for the redirect url with the token in it. It works fine but when we enable the token caching it just stores it in plain text on disk. It looked this PR in the JS client may have been addressing this issue. And like I posted up above this was called out in the java client as well here.

Without the client caching users are constantly having to do the SSO flow and that UX is pretty cumbersome.

[sfc-gh-sghosh]

Thank you @jsnb-devoted ,

Thanks for the update and for providing the reference of PRs in nodejs and Java driver.
We will evaluate and update you further about a similar fix in the Python connector.

Regards,
Sujan