You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
docs: phrase kernel 1.0.0 as forthcoming, not an existing version floor
1.0.0 is not published yet, so "carried by the native binary from 1.0.0
onward" overstated it as a shipping fact. Reword the Azure row and the
authType note: the connector forwards AzureSpM2m today, but its runtime
path needs the kernel Azure SP surface (kernel#282), which the currently
pinned 0.2.0 binary predates — it lands in a forthcoming release (planned
1.0.0, not yet published). U2M still needs no minimum. Row stays ✅ (the
options are read and forwarded per the legend).
Co-authored-by: Isaac
|`authType` — supported on both backends |`'access-token'`\|`'databricks-oauth'`\|`'static-token'`| ✅ | ✅ |`'access-token'`|`access-token` uses `token` (PAT) and is the default when `authType` is omitted. `static-token` uses `staticToken`; the kernel maps it to its native bearer-token mode. `databricks-oauth` covers M2M (`oauthClientId` + `oauthClientSecret`), U2M (browser; no secret), and — on an Azure host — Entra-direct service-principal M2M (see the `azureTenantId` / `useDatabricksOAuthInAzure` row). **Note:** the Entra-direct arm emits native `authMode: 'AzureSpM2m'`, which requires the kernel's Azure service-principal surface (kernel#282) — carried by the native binary from `1.0.0` onward. |
60
+
|`authType` — supported on both backends |`'access-token'`\|`'databricks-oauth'`\|`'static-token'`| ✅ | ✅ |`'access-token'`|`access-token` uses `token` (PAT) and is the default when `authType` is omitted. `static-token` uses `staticToken`; the kernel maps it to its native bearer-token mode. `databricks-oauth` covers M2M (`oauthClientId` + `oauthClientSecret`), U2M (browser; no secret), and — on an Azure host — Entra-direct service-principal M2M (see the `azureTenantId` / `useDatabricksOAuthInAzure` row). **Note:** the Entra-direct arm emits native `authMode: 'AzureSpM2m'`, which needs the kernel's Azure service-principal surface (kernel#282) — not in the pinned `0.2.0`binary; it lands in a forthcoming release (planned `1.0.0`, not yet published). |
61
61
|`authType` — Thrift-only |`'custom'`\|`'token-provider'`\|`'external-token'`| ✅ | ❌ | — |**Thrift-only.**`custom` uses `provider: IAuthentication`, `token-provider` uses `tokenProvider: ITokenProvider`, and `external-token` uses `getToken: TokenCallback`. The kernel throws `unsupported auth mode` for these modes. |
62
62
|`token` (PAT) |`string`| ✅ | ✅ | — (required for `access-token`) | Personal access token for `access-token` (the default mode). Thrift → `PlainHttpAuthentication` HTTP basic auth (username `token`). Kernel → native `Pat` authMode. Kernel rejects a blank/reserved token client-side (`AuthenticationError`) and rejects pairing it with OAuth fields; Thrift forwards it verbatim (a blank surfaces as a server-side 401). |
63
63
|`staticToken`|`string`| ✅ | ✅ | — (required for `static-token`) | Bearer/JWT for `static-token`. Thrift → `StaticTokenProvider.fromJWT` wrapped in `TokenProviderAuthenticator` (federation opt-in via `enableTokenFederation`). Kernel → native `Pat` bearer mode with federation always on (`federationClientId` ⇒ SP-wide WIF, omitted ⇒ account-wide). Kernel rejects a blank/reserved value; see the `enableTokenFederation` row. |
64
64
|`oauthScopes`|`Array<string>`| ❌ | ✅ | U2M `['sql','offline_access']`, M2M `['all-apis']`|**Thrift ignores `oauthScopes`** — `createAuthProvider` never threads it into `DatabricksOAuth`, so `authenticate()` always falls back to `defaultOAuthScopes` (`['sql','offline_access']`). Only the kernel honors a custom `oauthScopes`; its defaults happen to match Thrift's fallback. |
65
65
|`oauthClientId`|`string`| ✅ | ✅ |`databricks-sql-connector` when absent | OAuth client id, used on **both** U2M and M2M. Forwarded verbatim on both backends when set. When absent it defaults to `databricks-sql-connector` — Thrift via `getClientId()` for both flows; kernel via `oauthClientId ?? DEFAULT_OAUTH_CLIENT_ID` on M2M, and by letting the napi binding apply its own (identical) default on U2M. **Parity:**`oauthClientId` + no secret routes to **U2M** with the id forwarded (flow selection keys off `oauthClientSecret` presence — see that row), so it does **not** throw an M2M "secret required" error. |
66
66
|`oauthClientSecret` (M2M) |`string`| ✅ | ✅ | — | M2M client-credentials secret; its **presence** is the U2M-vs-M2M flow selector on both backends (`undefined` ⇒ U2M). Thrift → `DatabricksOAuth.clientSecret`. Kernel → native `oauthClientSecret` (workspace-OIDC M2M) or remapped to `azureClientSecret` (Entra-direct `AzureSpM2m`). A blank/reserved secret is forwarded verbatim and still selects M2M (Thrift parity) — except the Azure SP arm, which rejects it. |
67
-
| `azureTenantId` / `useDatabricksOAuthInAzure` | `string` / `boolean` | ✅ | ✅ | — | **Honored on both.** By design the kernel routes **all U2M** (no secret, any cloud) to its cloud-blind in-house OAuth U2M flow — there is no Azure-specific U2M mode, so `useDatabricksOAuthInAzure` is inert on U2M and every Azure workspace (including `.databricks.azure.us` US-gov) is always supported, on any kernel build. `useDatabricksOAuthInAzure` selects only the **M2M** mechanism on an Azure host: absent/`false` → Entra-direct service-principal M2M (native `AzureSpM2m` mode, creds ride `oauthClientId`/`oauthClientSecret`, `azureTenantId` optional — kernel auto-discovers from the workspace `/aad/auth` redirect when omitted); `true` → workspace-OIDC M2M. (`lib/kernel/KernelAuth.ts` `buildKernelConnectionOptions`.) The Entra-direct M2M arm requires the kernel's Azure service-principal surface (kernel#282), carried by the native binary from **`1.0.0`** onward; U2M needs no minimum. |
67
+
| `azureTenantId` / `useDatabricksOAuthInAzure` | `string` / `boolean` | ✅ | ✅ | — | **Honored on both.** By design the kernel routes **all U2M** (no secret, any cloud) to its cloud-blind in-house OAuth U2M flow — there is no Azure-specific U2M mode, so `useDatabricksOAuthInAzure` is inert on U2M and every Azure workspace (including `.databricks.azure.us` US-gov) is always supported, on any kernel build. `useDatabricksOAuthInAzure` selects only the **M2M** mechanism on an Azure host: absent/`false` → Entra-direct service-principal M2M (native `AzureSpM2m` mode, creds ride `oauthClientId`/`oauthClientSecret`, `azureTenantId` optional — kernel auto-discovers from the workspace `/aad/auth` redirect when omitted); `true` → workspace-OIDC M2M. (`lib/kernel/KernelAuth.ts` `buildKernelConnectionOptions`.) The connector forwards `AzureSpM2m` today, but its runtime path needs the kernel's Azure service-principal surface (kernel#282), which the currently pinned `0.2.0` native binary predates — it lands in a forthcoming kernel release (planned `1.0.0`, not yet published). U2M needs no minimum. |
68
68
|`persistence` (custom OAuth token store) |`OAuthPersistence`| ✅ | ❌ | — |**Thrift-only.** Kernel throws; it auto-persists U2M tokens to `~/.config/databricks-sql-kernel/oauth/` and does not cache M2M. |
69
69
|`enableTokenFederation` / `federationClientId`|`boolean` / `string`| ✅ | ⚠️ |`false` / — | On the kernel backend these options apply only to `static-token`. Federation is always enabled, so `enableTokenFederation` is ignored; an omitted or empty client ID selects account-wide WIF and a non-empty ID selects SP-wide WIF. Thrift honors the boolean and also supports these options for `token-provider` and `external-token`. |
0 commit comments