Auth Model and @anomaly IDs

Anomaly servers do not use Steam IDs as the primary player identifier. An Anomaly client authenticates with a persistent local identity, and the server assigns the resulting @anomaly ID to the player.

What the server verifies

When a player connects, Anomaly performs an asymmetric handshake before the player enters the round. The server verifies that the client controls the local identity it presents, checks that the client and server are compatible, and then accepts or rejects the connection.

Server operators do not need to configure keys or tune handshake settings. The important outcomes are:

• Vanilla clients are rejected.
• Mismatched Anomaly versions are rejected cleanly.
• Password-protected servers prompt clients before the join continues.
• Accepted players receive a stable @anomaly user ID.
• Plugins can read that ID from the normal LabAPI user-id surfaces.

Password-gated joins

Server operators can require a shared server password for Anomaly clients. When enabled, the client shows a password prompt during pre-join authentication before the player reaches the lobby.

The password is an access gate for joining the server. It does not replace @anomaly identity checks, user bans, whitelists, or remote-admin permissions.

Operational notes:

• Set, check, or clear the password from the server console with the password command.
• A wrong password rejects the join before gameplay.
• Repeated bad password attempts from the same IP may be temporarily blocked.
• Pressing Esc at the client prompt cancels the join attempt.

See Configuration for the password settings and command usage.

Where the ID appears

After a successful join, LabAPI-facing code sees an ID ending in @anomaly anywhere it would normally see a user ID.

Common places include:

• Player join events.
• Remote-admin permission checks.
• Ban, whitelist, and moderation plugins.
• Server-side mod companion code using LabAPI player objects.

The suffix is part of the ID. Copy the whole string exactly.

Remote-admin permissions

LabAPI’s RA permission system still keys off user IDs and permission strings. To grant an Anomaly user RA access, use their full @anomaly ID in the same place you would normally put a Steam ID.

# config_remoteadmin.txt example
$owner: abc123...xyz@anomaly, 76561198000000000@steam

Practical notes:

• Existing @steam permissions do not automatically migrate to @anomaly IDs.
• IDs are case-sensitive. Copy them from the player’s Launcher or server logs.
• If a player loses user.json, they lose the identity behind that ID and will appear as a new user.

No new permission token

Anomaly does not add a separate permission token such as @anomaly:verified. The @anomaly ID is a user identifier, not a permission by itself.

Diagnosing auth issues

If a client disconnects before joining, check for these broad causes:

Symptom	Usual cause
Version mismatch	Client and server are running incompatible Anomaly releases.
Non-Anomaly client rejected	A vanilla client tried to join an Anomaly-only server.
Password prompt appears	The server requires an Anomaly password before the join can continue.
Password rejected	The password was wrong, missing, or the source IP is temporarily blocked after repeated failures.
Identity rejected	The client’s local identity file is missing, invalid, or inconsistent.
Join takes too long	The client or server timed out during pre-join authentication.

For player-facing recovery steps, see Troubleshooting and Logs. For operator-side log triage, see Troubleshooting and Known Limitations.

Next

Asset Distribution and Late-Join Behaviour.