JarsAuth
A Minecraft client management mod that provides many features to manage client connections
📖About JarsAuth
JarsAuth
The description is generated by ChatGPT and proofread by the mod author.
In case of any ambiguity, please refer to Chinese texts.
For detailed Chinese description, please go to 客户端管理 (JarsAuth) - MC百科|最大的Minecraft中文MOD百科
If you want to leave a comment, please go to GitHub Discussion
Important Notice
The mod has been updated to version 6.0.
This is a major update, and configurations are NOT compatible with 5.x or earlier versions. Therefore:
- Server-side configurations must be regenerated
- Clients must also update the mod, but no client-side configuration is required
- Version 5.x contains a critical bug that causes abnormally high CPU usage and is no longer recommended
This issue has been fixed in 6.0
Configuration System Changes
All configurations have been migrated to an SQLite database
No scattered config files will be generated anymore
The database schema is identical across all versions, allowing easy migration
A built-in configuration tool is provided:
- Entry point: a new Manager button at the bottom of the server GUI
- Configuration must be performed in a GUI-capable environment
- If your server has no GUI:
- Configure locally first
- Then copy the database file to the server
- Remote configuration support may be added in the future
The mod JAR can also be run as an executable JAR, automatically using the database file in the working directory
The configuration tool includes detailed explanations
→ Hover over buttons to view tooltips
General Behavior
All features are optional and disabled by default
- If no configuration changes are made, the mod behaves as if it were not installed
Features only take effect on dedicated servers
- Supported environments: Forge, Fabric, Arclight, Mohist, etc.
- Singleplayer and LAN worlds are not affected
All messages are stored in language files (
*.json)- If you need to modify them, unpack the JAR, edit, then repackage before release
To ensure players’ right to be informed, all enabled features will be communicated to players in the form of system messages each time they connect. This message is mandatory and cannot be disabled.
Due to limited development resources:
- Only Minecraft 1.20.1 and later (stable releases) are supported
- 1.20.1 is the final Forge version
- Development will move to NeoForge afterward
- Custom development is available upon request
Feature 1 – File Checksum
This is the original feature of the mod.
Use Cases
Normally, mod loaders only check whether required mods match between client and server.
They do not detect:
- Client-only mods (e.g. minimaps, performance mods, cheat mods)
- X-ray or other resource packs
This severely impacts game fairness.
Traditional countermeasures (e.g. fake ores) may corrupt chunk data or cause lag.
This mod’s File Checksum feature can:
- Verify that all client-side files, including client-only mods, match the versions used when the modpack was created
- Detect unauthorized client-only files
Examples:
If minimaps are not allowed, clients with a minimap mod will be denied connection
If minimaps are required, clients missing it will also be denied
If the server updates some mods but clients do not:
- Mod loader checks may still pass
- Version mismatch can corrupt server data
→ This mod can block outdated clients by disabling their validation channel
How It Works
The mod scans all configured files and computes their hash values
All hashes are merged into a single client signature
When a client connects:
- The server periodically sends a list of files to verify
- The client computes and returns its signature
If the signature is not in the server’s record, the connection is rejected
Important Configuration Changes
Supports group-based management with inheritance
Different client groups can have different validation rules
Filters support:
- Simple wildcards
- Regular expressions
Exclusion filters can ignore files that should not be checked
(e.g..DS_Store,desktop.ini)
Feature 2 – Client Authentication
This feature functions similarly to a login system.
Use Cases
In offline-mode servers, player identity is based solely on usernames, making impersonation easy.
This feature adds a dedicated authentication mechanism, preventing other players from logging in using the same username.
How It Works
When a player joins:
- The server checks if an ID (UUID) exists for that username
If none exists:
- The player is treated as a first-time login
If one exists:
- The server requests the ID from the client
- If the client cannot provide it within a time limit, the connection is rejected
On first login:
- The server generates an ID bound to the username
- The ID is sent to the client and stored server-side
- The client is then disconnected and must reconnect for verification
Feature 3 – Server License
This feature can be used as an anti-addiction feature.
Use Cases
Servers may want to:
- Limit player playtime
- Require explicit server owner authorization
This feature provides a fine-grained whitelist system where:
The server issues licenses
Only players with valid licenses may connect
Licenses include:
- Expiration time
- Type
- Usage quota
How It Works
On login, the server checks the player’s license:
- No license
- License expired
- License quota exhausted
→ Connection is denied
Licenses are also revalidated periodically during gameplay.
This feature is entirely server-side and does not require client data exchange.
Important Configuration Changes
- Users and rules support grouping with inheritance
- Removed “connection-count–based” license type
- Added periodic licenses that automatically reset or clear quotas
Feature 4 – Signing & Obfuscation (Beta)
Note: This feature must be used inside a Minecraft environment.
Running the JAR directly does not support it.
Use Cases
Servers may want players to use only the modpack provided by the server.
This feature allows:
- Exporting signed mod packages to ensure uniqueness
- One-click generation of ProGuard obfuscation configs
Important Notice
- The mod release page only provides unsigned packages (“original packages”)
- Signed packages are never distributed from public web resource
- Server owners must decide whether to use signed/obfuscated versions
Setup
Starting from 6.0, strict network channel checks have been removed.
Client and server can run independently without breaking gameplay.
| Server Installed | Client Installed | Result |
|---|---|---|
| Yes | Yes | Validation follows configuration |
| Yes | No | Validation always fails if enabled; otherwise no validation |
| No | Yes | No validation |
| No | No | No validation |
Preparation Steps
Finalize your modpack and ensure:
- All mods and files are correctly placed
- Server and client can start and connect normally
Download the original package
Place it in both server and client
modsfoldersStart the server
Open the configuration tool via server GUI
Enable or disable required features in the Config tab
Signing (Optional)
In the Signing tab:
Generate:
*-signed.jar(server)*-signed-expanded.jar(client)
These must match exactly
A
config.profile is also generatedImport into ProGuard to generate:
*-signed-expanded-obj.jar
Obfuscation applies only to client packages
Replace:
- Server mod with server signed JAR
- Client mod with corresponding signed/obfuscated JAR
Restart the server
File Checksum Workflow
- Start client and server
- Run
/jarsauth record onon the server
(File Checksum must be enabled) - Client connects → files are recorded → client is disconnected
- Switch config tool pages to refresh UI
- Run
/jarsauth record off - Select client groups and configure filters
→ Changes apply immediately
Client Authentication Notes
Config tool shows:
- Server ID
- All recorded client IDs
To revoke a player:
- Delete their ID entry
Client-side:
A database file is created in the client root directory
It stores all username–ID mappings
Must be backed up carefully
- Loss → cannot log in
- Leak → account impersonation risk
- Multi-device use → copy the database file
Server License Notes
Configure groups in the tool
A mandatory
defaultgroup applies to all usersPlayers may belong to multiple groups
- Group relationship is OR
- If any group has remaining allowance, access is granted
All group allowance decrease simultaneously
- Effective allowance = highest available among groups
Configuration Reload Notice
- Configuration reload is no longer supported
- Enabling/disabling features requires a server restart
- Other configuration changes take effect immediately
Mod Author's Words
This part has been moved to GitHub.