auth describe: show U2M token storage location and source#5211
Merged
Conversation
Adds a "Token storage:" line to `databricks auth describe` output for profiles authenticated with `auth_type = databricks-cli` (U2M). Shows which backend the CLI uses for the token cache (plaintext file vs OS keyring) and where that choice came from (override flag, env var, config setting, or built-in default). Modeled on `gh auth status`, which surfaces "(keyring)" or the YAML hosts file path so users can tell at a glance where their tokens live. Mirrors the existing config-attribute "(from <source>)" annotation style. Other auth types (PAT, M2M, OIDC, etc.) do not use the U2M cache and the line is omitted for them. Resolver: `ResolveStorageModeWithSource` now returns a typed `StorageSource` instead of an opaque bool, so callers can render the source directly without duplicating the precedence-to-label mapping. Co-authored-by: Isaac
simonfaltum
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
simonfaltum
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
- Drop the "--auth-storage flag" wording from StorageSourceOverride.String(): no CLI command currently exposes a storage-mode flag, so promising one in the label was misleading. Switch to a generic "command-line override". When a flag is added later, that PR can replace the label at the call site. - For StorageSourceConfig, surface the resolved config file path (DATABRICKS_CONFIG_FILE or <home>/.databrickscfg) instead of hardcoding ".databrickscfg". Matches the SDK's existing config.Source style and no longer claims the wrong file when DATABRICKS_CONFIG_FILE is in use. Resolution stays in the describe command since that's the only caller that needs the user-facing path; the storage package keeps its resolver focused. - New acceptance tests cover the config-source path (u2m-plaintext-config) and the JSON output shape (u2m-json-output). Co-authored-by: Isaac
simonfaltum
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
simonfaltum
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
simonfaltum
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
simonfaltum
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
mihaimitrea-db
approved these changes
May 8, 2026
mihaimitrea-db
left a comment
mihaimitrea-db
left a comment
Contributor
There was a problem hiding this comment.
Could we have an acceptance test for the secure mode as well?
denik
pushed a commit
that referenced
this pull request
May 20, 2026
## Why
Users have no way to tell where the CLI is storing their U2M
(`databricks-cli`) token. As we move toward making secure storage the
default at GA, users need to confirm whether their tokens live in the OS
keyring or in `~/.databricks/token-cache.json`, and which precedence
level produced that choice. `gh auth status` does this with a
`(keyring)` or `(/path/to/hosts.yml)` suffix; we want the same.
## Changes
Before: `databricks auth describe` showed host, user, auth type, and a
"Current configuration" block, with no information about U2M token
storage.
Now: For profiles using `auth_type = databricks-cli`, output adds:
```
Token storage: plaintext, ~/.databricks/token-cache.json (from default)
```
or
```
Token storage: secure, OS keyring (service: databricks-cli) (from DATABRICKS_AUTH_STORAGE environment variable)
```
The `(from ...)` clause matches the existing config-attribute annotation
style. Other auth types (PAT, M2M, OIDC, Azure, etc.) do not use the U2M
cache and the line is omitted entirely (no field in JSON either).
JSON output adds a `token_storage: { mode, location, source }` object
alongside `details`.
Implementation:
- `libs/auth/storage/mode.go`: `ResolveStorageModeWithSource` now
returns a typed `StorageSource` (`Default | Override | EnvVar | Config`)
instead of an opaque bool. `StorageSource.String()` produces user-facing
labels matching `config.Source.String()` style.
- `libs/auth/storage/cache.go`: only existing in-repo caller updated to
use `source.Explicit()`.
- `cmd/auth/describe.go`: new `tokenStorageInfo` struct +
`resolveTokenStorageInfo` helper. Templates conditionally render the new
line. Only resolves when `auth_type == "databricks-cli"`; resolver
errors are debug-logged and treated as "no info available" rather than
failing describe.
No probing of either backend at describe time. The describe command
already makes a live API call that validates the token works;
double-probing would add a 3-second hang on Linux without Secret Service
for no extra signal. Following up with a `--check-token` flag is a
separate change if there's appetite for it.
## Test plan
- [x] Unit tests for `StorageSource.String()` and `.Explicit()`
- [x] Updated `TestResolveStorageModeWithSource` for the new return type
- [x] New `TestResolveTokenStorageInfo` table test covering U2M+default,
U2M+env, and non-U2M
- [x] New `TestGetWorkspaceAuthStatus_U2M_PopulatesTokenStorage` and
`TestGetWorkspaceAuthStatus_NonU2M_OmitsTokenStorage`
- [x] New acceptance tests at
`acceptance/cmd/auth/describe/u2m-plaintext-default/` and
`u2m-plaintext-env/`
- [x] Existing PAT acceptance test (`default-profile/`) still passes
unchanged
- [x] Manual smoke: built CLI, ran describe with U2M+default,
U2M+secure-env, and PAT profiles. Output is correct in both text and
JSON.
- [x] `./task checks` and `./task lint-q` clean
Secure-storage acceptance tests are intentionally omitted: they would
actually query the OS keyring on macOS (potential prompt) or hit the 3s
timeout on Linux CI without Secret Service. Unit tests cover the secure
path on any platform.
TanishqDatabricks
pushed a commit
to TanishqDatabricks/cli
that referenced
this pull request
May 22, 2026
…#5211) ## Why Users have no way to tell where the CLI is storing their U2M (`databricks-cli`) token. As we move toward making secure storage the default at GA, users need to confirm whether their tokens live in the OS keyring or in `~/.databricks/token-cache.json`, and which precedence level produced that choice. `gh auth status` does this with a `(keyring)` or `(/path/to/hosts.yml)` suffix; we want the same. ## Changes Before: `databricks auth describe` showed host, user, auth type, and a "Current configuration" block, with no information about U2M token storage. Now: For profiles using `auth_type = databricks-cli`, output adds: ``` Token storage: plaintext, ~/.databricks/token-cache.json (from default) ``` or ``` Token storage: secure, OS keyring (service: databricks-cli) (from DATABRICKS_AUTH_STORAGE environment variable) ``` The `(from ...)` clause matches the existing config-attribute annotation style. Other auth types (PAT, M2M, OIDC, Azure, etc.) do not use the U2M cache and the line is omitted entirely (no field in JSON either). JSON output adds a `token_storage: { mode, location, source }` object alongside `details`. Implementation: - `libs/auth/storage/mode.go`: `ResolveStorageModeWithSource` now returns a typed `StorageSource` (`Default | Override | EnvVar | Config`) instead of an opaque bool. `StorageSource.String()` produces user-facing labels matching `config.Source.String()` style. - `libs/auth/storage/cache.go`: only existing in-repo caller updated to use `source.Explicit()`. - `cmd/auth/describe.go`: new `tokenStorageInfo` struct + `resolveTokenStorageInfo` helper. Templates conditionally render the new line. Only resolves when `auth_type == "databricks-cli"`; resolver errors are debug-logged and treated as "no info available" rather than failing describe. No probing of either backend at describe time. The describe command already makes a live API call that validates the token works; double-probing would add a 3-second hang on Linux without Secret Service for no extra signal. Following up with a `--check-token` flag is a separate change if there's appetite for it. ## Test plan - [x] Unit tests for `StorageSource.String()` and `.Explicit()` - [x] Updated `TestResolveStorageModeWithSource` for the new return type - [x] New `TestResolveTokenStorageInfo` table test covering U2M+default, U2M+env, and non-U2M - [x] New `TestGetWorkspaceAuthStatus_U2M_PopulatesTokenStorage` and `TestGetWorkspaceAuthStatus_NonU2M_OmitsTokenStorage` - [x] New acceptance tests at `acceptance/cmd/auth/describe/u2m-plaintext-default/` and `u2m-plaintext-env/` - [x] Existing PAT acceptance test (`default-profile/`) still passes unchanged - [x] Manual smoke: built CLI, ran describe with U2M+default, U2M+secure-env, and PAT profiles. Output is correct in both text and JSON. - [x] `./task checks` and `./task lint-q` clean Secure-storage acceptance tests are intentionally omitted: they would actually query the OS keyring on macOS (potential prompt) or hit the 3s timeout on Linux CI without Secret Service. Unit tests cover the secure path on any platform.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Users have no way to tell where the CLI is storing their U2M (
databricks-cli) token. As we move toward making secure storage the default at GA, users need to confirm whether their tokens live in the OS keyring or in~/.databricks/token-cache.json, and which precedence level produced that choice.gh auth statusdoes this with a(keyring)or(/path/to/hosts.yml)suffix; we want the same.Changes
Before:
databricks auth describeshowed host, user, auth type, and a "Current configuration" block, with no information about U2M token storage.Now: For profiles using
auth_type = databricks-cli, output adds:or
The
(from ...)clause matches the existing config-attribute annotation style. Other auth types (PAT, M2M, OIDC, Azure, etc.) do not use the U2M cache and the line is omitted entirely (no field in JSON either).JSON output adds a
token_storage: { mode, location, source }object alongsidedetails.Implementation:
libs/auth/storage/mode.go:ResolveStorageModeWithSourcenow returns a typedStorageSource(Default | Override | EnvVar | Config) instead of an opaque bool.StorageSource.String()produces user-facing labels matchingconfig.Source.String()style.libs/auth/storage/cache.go: only existing in-repo caller updated to usesource.Explicit().cmd/auth/describe.go: newtokenStorageInfostruct +resolveTokenStorageInfohelper. Templates conditionally render the new line. Only resolves whenauth_type == "databricks-cli"; resolver errors are debug-logged and treated as "no info available" rather than failing describe.No probing of either backend at describe time. The describe command already makes a live API call that validates the token works; double-probing would add a 3-second hang on Linux without Secret Service for no extra signal. Following up with a
--check-tokenflag is a separate change if there's appetite for it.Test plan
StorageSource.String()and.Explicit()TestResolveStorageModeWithSourcefor the new return typeTestResolveTokenStorageInfotable test covering U2M+default, U2M+env, and non-U2MTestGetWorkspaceAuthStatus_U2M_PopulatesTokenStorageandTestGetWorkspaceAuthStatus_NonU2M_OmitsTokenStorageacceptance/cmd/auth/describe/u2m-plaintext-default/andu2m-plaintext-env/default-profile/) still passes unchanged./task checksand./task lint-qcleanSecure-storage acceptance tests are intentionally omitted: they would actually query the OS keyring on macOS (potential prompt) or hit the 3s timeout on Linux CI without Secret Service. Unit tests cover the secure path on any platform.