[FEATURE] Add device code authentication

[JoshLuedeman]

Use Case / Problem

Right now, if a user is using WSL with fabric cli and try to login to Fabric, the user login workflow opens File Explorer in the Windows environment instead of the browser.

Proposed Solution

Use the device code authentication workflow like most other Microsoft CLI products so that the bug in the user login flow described in #208 is no longer an issue. This is a better approach for command-line-only systems like WSL and should be the standard approach.

Alternatives Considered

pivot to SP and other approaches or use Windows PowerShell on machine

Impact Assessment

• This would help me personally
• This would help my team/organization
• This would help the broader fabric-cli community
• This aligns with Microsoft Fabric roadmap items

Implementation Attestation

• I understand this feature should maintain backward compatibility with existing commands
• I confirm this feature request does not introduce performance regressions for existing workflows
• I acknowledge that new features must follow fabric-cli's established patterns and conventions

Implementation Notes

No response

[microsoft-github-policy-service]

Thank you for submitting this issue, Josh Luedeman (@JoshLuedeman).
A member of the Fabric CLI team will review your submission and provide feedback shortly.

[github-actions]

AI Assessment: Needs Team Review

Introducing device code authentication for WSL and other non-GUI/command-line environments is a reasonable and consistent approach. Many Microsoft CLI tools (such as Azure CLI) adopt device code flow to maximize compatibility in headless or Linux environments. The current experience with browser-based login in WSL is problematic and not fully functional, which degrades usability.

However, implementing device code flow requires integration with the authentication library (likely MSAL), careful UX handling (to only trigger device code flow under certain environments/platforms), and potential updates to documentation and fab auth login behavior. This affects core authentication logic and cross-platform autopilot, which must be carefully evaluated to avoid regressions for users on other OSes and to meet security/support policies for Microsoft account flows.

This change directly affects CLI core user authentication, and so team review is necessary to ensure alignment with Microsoft Fabric platform auth guidance, avoid breaking existing scripted workflows, and determine the correct default and override behaviors.

Next Steps

🔔 Escalated to team — This issue requires team review and has been flagged for attention.

---

💡 If this issue requires the team's attention and was not escalated, you can tag @microsoft/fabric-cli-dev to notify the team.

[github-actions]

🔔 @microsoft/fabric-cli-dev — This issue has been flagged by AI triage as requiring team attention. Please review the assessment above.

[HasanAboShally]

Josh Luedeman (@JoshLuedeman) — agreed, this is a gap and we're on it.

Why not just a service principal? SPN works without a browser today and is the right call for CI/CD, but it's a non-human identity — actions run as the SPN, not as you. Device code is for logging in as yourself, with your own conditional access and MFA, on a machine with no browser. Different jobs.

The shape we'd want is an explicit opt-in flag — fab auth login --use-device-code, mirroring az login --use-device-code. MSAL already supports the flow, so the work is mostly UX. I can't commit to a release yet, but it's a reasonable ask and on our radar.

cc #208, #50 — same auth theme.

[iemejia]

I'd like to add another use case that makes this feature essential beyond the WSL scenario described above.

Headless servers and environments without browser/URL access are a common deployment scenario for Fabric CLI. This includes:

- SSH sessions to remote servers the most typical sysadmin/data engineer workflow; there is no local browser to open
- Docker containers running fab inside a container for automation or reproducibility
- Cloud VMs without desktop environments Azure VMs, EC2 instances, or on-prem Linux servers with no GUI
- CI/CD runners GitHub Actions, Azure DevOps agents, Jenkins nodes (for interactive auth scenarios that can't use service principals)
- VS Code Remote / Codespaces terminal where the browser redirect from the CLI may not reach the user's local browser

In all these cases, fab auth login currently fails or is unusable because it tries to open a browser URL that the environment cannot reach. Device code flow (--use-device-code) solves this cleanly: the CLI prints a code and a URL, and the user completes authentication on any device that has a browser.

This is the established pattern across Microsoft CLI tools az login --use-device-code has supported this since the early days of Azure CLI, and users expect the same from fab.

I have a working implementation at #257 (closed per process) that I'm happy to resubmit once this issue gets a help-wanted label and the team confirms the approach. The implementation covers:

• --use-device-code CLI flag + interactive menu option
• MSAL initiate_device_flow / acquire_token_by_device_flow integration
• Silent token refresh for subsequent scopes (user enters code only once)
• Full test coverage (19 tests: 8 command-level, 11 core-level)

Happy to discuss the approach or adapt it to whatever direction the team prefers.