Support user-level (federated) authentication for SQL integrations instead of shared service-account credentials, with the OAuth flow and credential storage handled by the extension.
Done
Remaining
- Snowflake user-level auth. The extension only offers
PASSWORD and SERVICE_ACCOUNT_KEY_PAIR (SUPPORTED_SNOWFLAKE_AUTH_METHODS). The remaining Deepnote auth methods need a local flow: NATIVE_SNOWFLAKE (external browser SSO), OKTA, AZURE_AD, and user KEY_PAIR.
- Any further provider follows the BigQuery pattern: a local OAuth or SSO flow in the extension, credentials in SecretStorage, per-cell token injection, and token refresh.
Constraint
The toolkit's own federated path (_get_federated_auth_credentials in sql_execution.py) fetches tokens from Deepnote Cloud using the user pod auth context, so it is not usable from a local kernel. Each provider has to be implemented on the extension side, as BigQuery was.
Support user-level (federated) authentication for SQL integrations instead of shared service-account credentials, with the OAuth flow and credential storage handled by the extension.
Done
FederatedAuthSqlBlockCodeGenerator. Federated configs are deliberately excluded from the kernel environment so client secrets never reach the kernel.Remaining
PASSWORDandSERVICE_ACCOUNT_KEY_PAIR(SUPPORTED_SNOWFLAKE_AUTH_METHODS). The remaining Deepnote auth methods need a local flow:NATIVE_SNOWFLAKE(external browser SSO),OKTA,AZURE_AD, and userKEY_PAIR.Constraint
The toolkit's own federated path (
_get_federated_auth_credentialsinsql_execution.py) fetches tokens from Deepnote Cloud using the user pod auth context, so it is not usable from a local kernel. Each provider has to be implemented on the extension side, as BigQuery was.