Authentication and permissions

DisplayNet has one user model, shared by every transport and by DisplayNet Manager. A user is the same user, with the same role, whether they arrive over telnet, SSH, a WebSocket, REST, or the web interface.

Authentication requirement

A server setting decides whether clients must authenticate at all:

authentication_required	A client that does not authenticate
true	Is rejected until it does
false	Is accepted, and treated as the built-in DisplayNet user

The setting is read with config:

Read the current setting
config get server authentication_required

Do not depend on unauthenticated access

A client that skips authentication works while the setting is off and stops working the moment an installer turns it on. Authenticate unless you control the deployment and know it will never be enabled.

The built-in DisplayNet user is not an administrator, so a client relying on it also loses every Admin command.

Roles

There are two: User and Admin. Every command declares the minimum role it needs, and a caller below it is refused with Permission Denied on every transport.

Most of the API is User. The Admin-only surface is, broadly, everything that changes the server itself or the fleet's membership:

Entirely Admin	What it covers
server	Power, service restarts, front panel, database maintenance
user, authkey, cert	Accounts, SSH keys, TLS certificates
claim, release, auth, unauth	Which devices belong to this system
replace, cache	Device replacement and cache recovery

Routing, presets, walls, MultiView and tagging are all User.

Role discovery

The OpenAPI document exposes each operation's requirement as x-displaynet-min-role, so a generated client can read it before making the call. Neither help nor GET /api/commands reports it; the OpenAPI document is the only runtime source.

Login tokens

Authenticating produces a login token, and it is the same token whichever route issued it:

• login on a session transport
• POST /api/displaynet/login over REST
• signing in to DisplayNet Manager

A token obtained one way is valid on the others. Its lifetime comes from the server's login-token expiry setting, so a long-lived integration can hold one rather than authenticating per request. logintoken authenticates a session with a token instead of a password, and user invalidatelogintoken revokes one.

Authentication by transport

Transport	Mechanism
Telnet, SSH, WebSocket	The login command, as part of session initialization. The session then carries the identity until it closes.
REST	An Authorization: Bearer <token> header on every request. See REST authentication.

SSH encrypts the connection but does not authenticate to the API; an SSH client still logs in separately.

See also

• Choosing a transport: what else is shared across the four
• Connection State: the DN_AUTHENTICATION reply and its auth_details
• REST authentication: obtaining and sending a bearer token