> ## Documentation Index
> Fetch the complete documentation index at: https://docs.idun-group.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Authentication

> Admin-panel auth modes (`none` / `password`) and the environment variables that drive them.

The standalone has two distinct authentication surfaces. This page covers the admin panel; for agent-route SSO, see [SSO](/auth/sso).

| Surface           | Routes                                   | Mechanism                                             | Where it lives                                |
| ----------------- | ---------------------------------------- | ----------------------------------------------------- | --------------------------------------------- |
| **Admin panel**   | `/admin/*`, `/login/`, `/admin/api/v1/*` | `none` or `password` (bcrypt + signed session cookie) | Environment variables                         |
| **Agent runtime** | `/agent/*` (chat side)                   | OIDC JWT validation with per-user allowlists          | `sso:` block in config — see [SSO](/auth/sso) |

Health and metadata routes (`/health`, `/_engine/info`) stay open on both surfaces. Treat the engine as a process running inside a trusted boundary; see [Production hardening](/deployment/hardening) for network-layer controls.

## Environment variables

The admin panel is configured by environment, not config. The mode is selected by `IDUN_ADMIN_AUTH_MODE`.

| Variable                   | Default | Description                                                                                                                                                    |
| -------------------------- | ------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `IDUN_ADMIN_AUTH_MODE`     | `none`  | Admin gate. `none` for laptop dev; `password` for containers and shared deployments.                                                                           |
| `IDUN_ADMIN_PASSWORD_HASH` | empty   | Bcrypt hash that seeds the singleton admin row on first boot. Required when `auth_mode = password`. Generate with `idun hash-password`.                        |
| `IDUN_SESSION_SECRET`      | empty   | At least 32 characters. Signs the `idun_session` cookie. Required when `auth_mode = password`; startup fails fast if shorter.                                  |
| `IDUN_SESSION_TTL_HOURS`   | `24`    | Session cookie lifetime in hours (range `1..720`). Sliding renewal extends the cookie on every request.                                                        |
| `IDUN_ALLOW_OPEN_ADMIN`    | `false` | Opt-in flag that lets `auth_mode=none` bind `0.0.0.0` / `::`. Containers and trusted networks only. Without this, an open-admin process is forced to loopback. |

## `IDUN_ADMIN_AUTH_MODE=none`

Every admin route is open. No login screen. Anyone who can reach the process can read and write configuration through `/admin/`.

Intended for laptop development. The runtime binds to `127.0.0.1` by default so the open admin is not exposed beyond `localhost`. To bind to `0.0.0.0` (e.g., inside a container) you must set `IDUN_ALLOW_OPEN_ADMIN=1` — the runtime refuses otherwise.

## `IDUN_ADMIN_AUTH_MODE=password`

A single admin user logs in at `/login/` with a password. The standalone signs an `idun_session` cookie (`HttpOnly`, `SameSite=Lax`, `Secure` when behind HTTPS) and gates `/admin/*` on it. The published container image flips this mode on by default.

Setup is two env vars at first boot:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
# 1. Generate the bcrypt hash on a workstation (never on the server).
idun hash-password
# Password: ********
# Confirm:  ********
# $2b$12$abc...   <- copy this

# 2. Inject both at deploy time.
IDUN_ADMIN_AUTH_MODE=password \
IDUN_ADMIN_PASSWORD_HASH='$2b$12$abc...' \
IDUN_SESSION_SECRET="$(openssl rand -hex 32)" \
idun serve
```

`IDUN_ADMIN_PASSWORD_HASH` is consumed only on first boot to seed the singleton admin row. Subsequent boots ignore the env var. Rotate the password from the admin UI, or truncate the `standalone_admin_user` table and reboot to re-seed from the env.

<Note>
  The standalone supports **exactly one admin user**. The `standalone_admin_user` table has a fixed primary key of `"singleton"` and the admin URL never carries an id. There is no allowlist or multi-user concept for the admin panel today. For per-user policy, restrict access at the network layer (VPN, mTLS gateway, IP allowlist on the load balancer). See [Production hardening](/deployment/hardening) for the full checklist.
</Note>

## What's next

<Card title="SSO" icon="lock" horizontal href="/auth/sso">
  Per-agent OIDC for `/agent/*` runtime routes, with `allowed_domains` / `allowed_emails` allowlists.
</Card>

<Card title="Production hardening" icon="shield" horizontal href="/deployment/hardening">
  Env-var checklist for `password` mode + reverse-proxy / TLS notes.
</Card>

<Card title="Troubleshooting" icon="wrench" horizontal href="/troubleshooting">
  What `agent_not_ready` and reload-pipeline errors mean.
</Card>