Identity and access
Access in WingGate is granted, never implied. This article describes how users authenticate, how identity credentials are kept apart from asset credentials, and how every operation is scoped by the authorization chain.
Sign-in: password + MFA, SSH public keys, external identity
Every account completes MFA enrollment before interactive use: enroll a first MFA factor, either a TOTP authenticator or a passkey (WebAuthn). Local password sign-in requires the password plus any active MFA factor; when a passkey is enrolled, sign-in uses it first and falls back to TOTP. Registering a passkey issues one-time recovery codes as the sign-in fallback when the device is lost. SSH access from your own client uses public-key authentication against WingGate's SSH endpoint; WingGate never holds your private key. External identity providers (OAuth) are supported for sign-in, with the provider callback completing on the service and never touching asset credentials.
Identity credentials and asset credentials are isolated
Your login credentials (password, TOTP or passkey, external identity) authenticate you to WingGate. The credentials used to reach a target asset (SSH keys, passwords) are a separate class: on an SSH host they are stored against that asset's connection profile, while an SMB / WebDAV / S3 file backend stores them in a separate credential record the asset references. Neither is ever mixed with your login session, and compromising one does not expose the other.
Authorization chain: Organization, Project, Grant
An Organization groups assets and members. A Project groups the assets a member may use after they hold a coarse Project access grant. A grant authorizes (project, user) for that Project's full data plane — Web Terminal, SSH client, file tools, and MCP. It cannot pick a subset of operations. Finer MCP limits come from Project/asset MCP configuration, not from the grant. Management actions use a fixed Owner/Admin/Member role matrix — there is no configurable permission engine. Revoking a grant takes effect on the next authorization check.
What each access method can do
Each access method has a fixed permission set. A coarse grant covers every method in the Project; it cannot invent wider permissions.
| Access method | Capabilities | How you connect |
|---|---|---|
| Web Terminal | Interactive terminal, with optional file tools | In-browser, through the service |
| SSH client | Interactive shell, as granted | Your SSH client to the SSH endpoint |
| SSH Direct | Interactive shell, as granted | Your SSH client to the connector's local SSH listener |
| MCP — file | File tools: ls, read, fetch, upload, write, edit, mkdir, rename, delete (shared by SSH / host and SMB / WebDAV / S3), plus find and grep on SSH / host | MCP client to the connector's MCP ingress |
| MCP — command | One-shot, non-PTY shell commands | MCP client to the connector's MCP ingress |
| MCP — browser | Session, tab and page control on your browser assets, plus discovery/calling of page-level WebMCP tools | MCP client to the connector's MCP ingress |
| MCP — notify | browser.notify: a one-way system banner to the local user |
MCP client to the connector's MCP ingress |
Session lifecycle
Every interactive connection is a Session with an explicit lifecycle: creation, active use, and termination. Sessions can be revoked, which tears down the underlying connection. What the audit trail records about sessions and everything else is covered in Audit and evidence.