Docs / Guides
Dashboard authentication
By default, whichever surface you enable (.AddAxonDashboard() or
.AddAxonApiEndpoints()) is open to anyone who can reach it — no
login required. Chain .AddAuthentication(...) to require username/password
sign-in.
builder.Services.AddAxonServer()
.AddAxonDashboard()
.AddAuthentication(auth =>
{
builder.Configuration.GetSection("Axon:DashboardUsers").Bind(auth.Users);
});
If you skip .AddAuthentication(...), Axon logs a startup warning so an open dashboard doesn't go unnoticed.
Configuring users
Dashboard access is username/password with per-user roles: Admin users can view
and take actions (retry, delete, trigger); ReadOnly users can only view.
Configure one or more users (appsettings.json, environment variable, or any
other IConfiguration source):
{
"Axon": {
"DashboardUsers": [
{ "Username": "admin", "Password": "P@ssw0rd", "Role": "Admin" },
{ "Username": "viewer", "Password": "P@ssw0rd", "Role": "ReadOnly" }
]
}
}
Passwords are configured in plain text (matching most secrets-manager/env-var workflows) but are never stored or compared in plain text at runtime: each is hashed once at startup with PBKDF2-HMAC-SHA256 and a random per-user salt, and only that hash is held afterward.
Coexisting with your own auth
Axon's dashboard auth uses its own cookie scheme (AxonDashboard) and never sets
itself as the app's default authentication scheme, so it coexists safely with a host app's
own AddAuthentication(...) (JWT bearer, its own cookie, etc.) — enabling one
doesn't override or get overridden by the other, regardless of registration order.
Rate limiting and auditing
Login attempts are rate-limited two ways: by client IP (5 attempts per 5 minutes) and by username (5 failures locks that username out for 5 minutes, independent of which IP the attempts came from) — either can trip first depending on the attack shape.
Every login attempt and every write action (job retry/delete, recurring-job trigger/delete)
is logged under the Axon.Server.Services.AxonAuditLog category with the acting
username, so audit events can be routed/retained separately from regular application logs
without touching your logging configuration.