Repository navigation
[FEATURE] Multi-account session management #206
Description
Problem
Consultants and developers who work across multiple Microsoft Fabric tenants and client environments face a painful workflow today: every time they need to switch context, they must run fab auth logout followed by a full fab auth login, re-authenticating interactively each time.
Real-world use case
A typical consulting scenario:
- Client A - Production tenant
tenant-aaa, userconsultant@clientA.com - Client B - Dev/test tenant
tenant-bbb, userconsultant@clientB.com - Internal - Corporate tenant
tenant-ccc, userme@mycorp.com
Switching between these today requires a full logout/login cycle for each transition, which is disruptive, slow, and breaks automation scripts that assume a persistent session.
Proposed solution
Add stored user session management to the CLI so that multiple interactive authentication sessions can coexist and be switched instantly:
| Command | Description |
|---|---|
fab auth list |
List all stored user sessions with active/valid status |
fab auth switch |
Switch to another stored session (interactive or direct) |
fab auth switch -u <account> -t <tenant> |
Switch directly to a specific account (case-insensitive) |
fab auth logout -u <account> |
Log out a specific session without affecting others |
fab auth logout --all |
Clear all stored sessions |
Behavior
- Two stored sessions, no flags:
fab auth switchautomatically toggles to the other account. - Three or more sessions, no flags: an interactive prompt is shown.
- With
-u(and optionally-t): switches directly, no prompt. - Sessions are validated against the MSAL token cache and marked as valid/invalid in
fab auth list. - Environment variable authentication (
FAB_TOKEN, etc.) takes precedence and blocks session switching with a clear error message. - Interactive login now preserves the broker-backed MSAL app across the Fabric, OneLake, and Azure token warm-up so newly selected accounts are stored cleanly on Windows.
Acceptance criteria
-
fab auth listshows all stored sessions with active/valid/last_used metadata -
fab auth switchsupports direct (-u,-t) and interactive selection -
fab auth logoutsupports per-session removal (-u,-t) and bulk (--all) - Username matching is case-insensitive
- Session switching is blocked when env var auth is active
- Documentation and examples are up to date
- Tests cover happy paths and edge cases
Metadata
Metadata
Assignees
Labels
No labels
Activity
microsoft-github-policy-service commentedon Apr 7, 2026
Thank you for submitting this issue, Mathieu Turcotte (@Mathf18).
A member of the Fabric CLI team will review your submission and provide feedback shortly.
[-]feat: Multi-account session management for interactive authentication[/-][+][FEATURE] Multi-account session management for interactive authentication[/+][-][FEATURE] Multi-account session management for interactive authentication[/-][+]feat: Multi-account session management[/+][-]feat: Multi-account session management[/-][+][FEATURE] Multi-account session management[/+]HasanAboShally commentedon Jun 1, 2026
Mathieu Turcotte (@Mathf18) — this is a well-thought-out proposal and it maps to a real pain point. Consultants and partners working across tenants shouldn't need a full logout/login cycle to switch context.
Here's where we stand:
fab auth switchauto-switch if only 2 sessions exist? (You proposed yes — we're leaning the same way.)fab auth listand prompt re-auth on next switch.)This is on our backlog. I can't commit to a specific release yet, but the proposal is solid and we'll reference it when we pick this up. If the community votes this up (thumbs-up on the issue), it'll help us prioritize.
Thanks for the detailed acceptance criteria — that saves us design time.
Mathf18 commentedon Jun 1, 2026
Perfect thank you Hasan !
At the moment, I worked around this by building a small PowerShell script that keeps my Fabric CLI profile/context separated per folder. This lets me work across multiple client projects without constantly switching things manually.
The main issue I ran into was keeping the
fabtoken persistent compared with the Azure CLI token, but I found aworkaround by leaning on the Azure auth context to keep things alive longer.
Native profile/context support in
fabwould still be really helpful for multi-client workflows.erlendoeien commentedon Sep 14, 2026
Pinging this, as I would love a concurrent/multi-tenant auth feature as this is a repeating pain point in my workflows using fabric-cli.