There are several ways into Xedant Agent. Through the browser — a regular login with a login and password, or single sign-on through your server, where the agent opens by itself, with no form. From other programs — with an API key (a secret code that lets a program talk to the agent) for sending commands, and through live connections for events in real time. Whichever way you choose, the agent issues the same “digital pass” (a JWT token) valid for 90 days — it keeps your session alive until it expires, so you don’t have to sign in again. Below is how each method works and what to set up for it.
Regular login
The simplest way: type your login and password on the login page. The credentials are set with the environment variables AGENT_LOGIN (the login) and AGENT_PASSWORD (the password) — an environment variable is a setting the app reads when it starts. The password is stored as a SHA-256 “fingerprint” (a one-way code the original password cannot be recovered from), and if the variables are not set, the app generates a temporary password itself (the login is code) and prints it in the console.
A regular login gives you the user role. For the full picture — where the credentials come from, how to set the variables, and what the “digital pass” is — see the Getting Started page.
Single sign-on through your server (SSO)
Single sign-on (SSO — “sign in once, authorized everywhere”) saves you from typing a password into every agent. It turns on when the agent is deployed on a server through Xedant MultiAgent: the server gets a central login (Authelia behind an nginx gateway — nginx is the web server that stands in front of all the apps). You sign in to the server once, and every agent opens right away, with no second login.
How it works
Step by step:
- The gateway lets only signed-in users through. nginx checks the central login and passes only authorized users to the agent. Along the way it adds service headers to the request:
Remote-User(the username),Remote-Groups(the user’s groups, comma-separated), andX-SSO-Token(the gateway’s shared secret); - The agent checks the secret. When a request arrives, the agent compares
X-SSO-Tokenwith its own environment variableSSO_PROXY_TOKEN. If they match andRemote-Useris not empty, the agent issues its usual “digital pass”; - The role comes from the group. If
Remote-Groupscontains the groupmanager(case-insensitive), the user gets the Manager role; otherwise, the regular user role; - Silent sign-in. When the app opens, it quietly tries this route (for no longer than ~5 seconds). If it gets a token, the app opens right away and the login form is never shown. If the route is unavailable (the agent runs without a central login, or the gateway redirected to its own page), the regular login form appears as before.
What to set up
You only need one environment variable: SSO_PROXY_TOKEN, holding the same secret as the gateway. MultiAgent writes it into the agent’s environment when deploying with a central login. If the variable is not set, the feature is fully off — everything works as before, with the login form.
Why this is safe
- The headers count only when
X-SSO-TokenmatchesSSO_PROXY_TOKEN; the comparison runs in constant time, so a mismatch reveals nothing that would help anyone guess the secret; - nginx overwrites these headers, so they cannot be forged from a browser — only the gateway itself adds them;
- The secret is not stored in the database and never appears in logs — it cannot be read from inside the system;
- Direct access at
host:port(bypassing the gateway) does not go through the central login and works as before — with the authorization form.
API-key authorization
To let other programs control the agent without a browser, set the environment variable AGENT_API_KEY — it holds the SHA-256 “fingerprint” of the access key. The program sends the key itself in the X-API-Key header, and it carries the Manager role — full access, the same as signing in as the manager. For details and request examples, see the API page.
Live connection authorization (SignalR)
Live connections (SignalR — the technology that pushes events from the server the moment they happen) let you follow chat events in real time instead of asking the server over and over. Authorization there is built on the same “digital pass” or API key:
- The browser interface passes its JWT token as the
access_tokenquery parameter when connecting — a WebSocket connection cannot carry headers; - External programs pass the same API key — in the
X-API-Keyheader or as theapi_keyquery parameter (for WebSocket the query parameter is mandatory, because headers cannot be set).
For details about live events and their authorization, see the API page.
Summary table of access methods
A quick look at each method — when you need it and what proves your access:
| Method | When it is used | What proves access | Details |
|---|---|---|---|
| Regular login | signing in to the interface with a login and password | AGENT_LOGIN / AGENT_PASSWORD | Getting Started |
| Single sign-on (SSO) | the interface behind the MultiAgent server’s gateway | gateway headers + the SSO_PROXY_TOKEN secret | this article |
| Manager login | external fleet management from MultiAgent | MANAGER_PASSWORD | API |
| API key | commands from other programs | X-API-Key / AGENT_API_KEY | API |
| Live connections | events in real time | the access_token or api_key token | API |
Related sections
- Getting Started — installation, credentials, and your first login;
- API — programmatic access: commands, the live subscription, and key-based authorization;
- Models — environment variables, including keys and secrets;
- Backends — signing the AI in with a Claude subscription (Pro/Max): that pays for the AI, it is not access to the agent itself.
← Back: Chat Labels
Next: API →