Identity & SSO for organizations

One sign-in carries the whole app: desktop, chat, dashboard, and CLI connections. This page explains how enforced SSO works, what it deliberately disables, and how a customer identity provider comes online.

Wingman has two sign-in worlds. Axelera employees click Continue with Axelera SSO: the browser opens, Microsoft Entra accepts the session, and Wingman returns signed in — no passwords are typed inside the app. Customer deployments work the same way against the customer’s own identity provider. Deployments without enforced SSO can also offer email-plus-password and OAuth sign-in, but an enterprise deployment is expected to run SSO-only.

One session, every surface

The session is genuinely singular. The desktop app registers an authentication provider named Axelera Wingman SSO in the editor’s Accounts menu — that one session backs Wingman Home, Agent Dev, the dashboard panels, and the MCP connections your local CLIs use. Opening Chat performs a server-side exchange-code handoff: the desktop hands your session to hosted chat without putting tokens in URLs, which is why you may see a one-time confirmation page — click Continue and you are in chat as your SSO user. There is no query-token fallback and no parallel identity path.

The server decides enforcement

Whether SSO is enforced is decided by the server, not the client. Each deployment serves its auth strategy — enterprise-sso or standard — from its public configuration endpoint, and every surface reads it from there. The two surfaces do not fail the same way, though, and that matters on a shared machine. If the web app cannot read the strategy it refuses to sign anyone in. If the desktop app cannot read it, it falls back to its local provider setting, and with no setting it treats the deployment as standard — so a network fault can leave the desktop offering password sign-in on a deployment that enforces SSO. Hosted chat is separate again: it gates password sign-in on its own configuration rather than on this strategy.

What enforced SSO disables

Onboard a customer provider

Onboarding a customer identity provider is a registration step on the Axelera side, then a visible change on yours. Until your provider is registered, the sign-in screen shows the customer button as Customer sign-in unavailable (employees can still continue with Axelera SSO). Once Axelera registers your provider’s federation metadata for your deployment, the button becomes an active Sign in and your users authenticate against your own tenant. Plan a pilot: validate one machine end to end — desktop sign-in, Chat handoff, first CLI tool call — before rolling out.

Local CLIs join the session

Local CLIs join the same session on first use: when Claude Code, Codex, or Kimi first calls a Wingman tool, the browser opens an approval for the authenticated MCP connection. There are no shared bearer tokens or static headers to distribute — each user’s connection is their own.

Sign-out on shared machines

Signing out is a full teardown, built for shared machines. From the status bar account menu, Sign Out clears the Wingman session, explicitly disconnects the CLI OAuth connections it authorized, stops the local MCP bridge and deletes its secret, and closes the integrated chat tab along with its persisted session. Only the chat teardown is isolated: the earlier steps share one failure path, so if disconnecting the CLI connections throws, the Wingman session itself may not be cleared. On a shared machine, confirm the account menu shows you signed out before walking away. The same menu offers Sync Authentication to refresh a session without signing out.