AuthMeReloaded puts a login gate in front of an offline mode server

Why a server in offline mode needs its own login

The problem the plugin states is username theft, and the mechanism is that in offline mode the client is trusted about who it is. The README says to use it to secure your offline mode server, or to increase the protection of an online mode server.

The consequence of an unauthenticated player being let loose on an offline mode server is that the server believes whatever name the client claims. So the plugin disallows players who are not authenticated from doing actions like placing blocks, moving, typing commands or using the inventory. It can also kick players with uncommonly long or short player names, and kick players from banned countries, which is a different kind of protection, against a flood of badly named accounts or an unwanted region.

There is a second, subtler piece of value. Because a player is not fully in the world until they authenticate, several secondary protections become possible. The plugin protects a player's inventory until correct authentication, which requires PacketEvents. Ender pearls thrown before authentication are returned to the player on login, so a player cannot grief with them before proving who they are. The quit location is saved. And a separate timeout applies to login and to registration, so a server can be slow about one and impatient about the other.

The audience is the server administrator who has to decide what an unauthenticated player can and cannot do, and who wants that decision expressed in a configuration file rather than in a wall of event handlers.

One more thing the README mentions is the Session Login feature, which means the authentication command does not have to be executed every time the player connects.

Eight build targets for eight ways of running a server

The repository layout is where the compatibility story lives, and it is unusual to have this many separate artifacts in one project.

There is authme-core/, which is the shared implementation, and then a build per server flavour. authme-spigot-legacy/ covers Spigot Legacy, the README putting that at versions 1.16 to 1.19, authme-spigot-1.21/ covers the newer Spigot line, authme-paper/ and authme-paper-common/ cover Paper 1.21 and above, and authme-folia/ covers Folia 1.21 and above. On top of that sit the proxy plugins, authme-bungee/ for BungeeCord and authme-velocity/ for Velocity, plus authme-tools/ for the tooling.

The reason this matters is that these are not interchangeable. A plugin compiled against Paper's API will not load on Spigot, and a Folia plugin is not the same thing as a Paper plugin because Folia regionalises the server. The README lists dedicated builds as the first feature, and the project publishes a separate artifact for each combination, so a server administrator downloads the one that matches their platform rather than a universal jar.

The proxy plugins are a different category again. A BungeeCord or Velocity network has several backend servers, and the login state has to be shared across them, so the proxy plugin is where the authentication actually happens and the backend plugin enforces it. That is why the README describes the plugin as having native proxy plugins rather than a bolt on.

The repository also has authme-paper-common/, which suggests the Paper and Folia builds share a layer, and the samples/ directory holds a databases/ folder and a website_integration/ folder, the latter pointing at the common request of talking to the same user database from a website.

Four backends and a long list of hash algorithms

The storage and cryptography options are where an authentication plugin either earns trust or does not, and the feature list covers both in detail.

On the database side the plugin supports MySQL, MariaDB, PostgreSQL and SQLite:

  <li><strong>MySQL, MariaDB, PostgreSQL and SQLite Backend support!</strong></li>

It also supports custom MySQL table and column names, which the README says is useful with forum databases, so an existing phpBB or vBulletin user table can be reused rather than duplicated. Queries are cached, which matters on a busy server where a login check is on the hot path.

On the password side, the supported encryption algorithms are SHA256, ARGON2, BCRYPT, PBKDF2 and PBKDF2BASE64, with the full list in a document in the docs directory. The presence of ARGON2 and BCRYPT is the point: those are the memory hard and salted choices, and SHA256 in that list is the legacy option you migrate away from rather than towards.

The migration story is unusually good. The plugin supports hashes from external systems for zero downtime migration, and the README names the formats: XFBCRYPT, MYBB, PHPBB, JOOMLA, WORDPRESS, WBB3 and WBB4, and IPB3. That means a server that currently authenticates against a forum database can move players over without asking every user to reset their password, which is the single biggest obstacle to consolidating authentication plugins.

The repository also has a docs/ directory at the root holding the configuration guide, the hash algorithm list and the translations list, and the README points to docs/config.md for how to configure the plugin.

Importers and a built-in SQLite to server database migration

The migration theme runs through the whole feature list, not just the hashing part.

There are account importers for Auth+, LibreLogin, LimboAuth, nLogin, OpeNLogin and tiAuth, which is a list of other authentication plugins that server administrators actually use. The importers move accounts from those systems into AuthMeReloaded's own tables.

And there is a built-in migration path between storage engines: SQLite to MySQL, MariaDB or PostgreSQL, and the reverse direction is implied by the same mechanism. That matters for a specific and common scenario. A small server starts with SQLite because it is one file and no setup, and it grows into a network that needs a real database. Doing that by hand means exporting and re-importing user tables while the server is down, and getting the schema and the password hashes byte identical, which is exactly the part people get wrong. A built-in path reduces that to a configuration change and a command.

Two related features make the same migration less painful. The plugin can accept hashes from external systems, so a player authenticating with a forum password is not forced to have two accounts with two passwords, and the ForceLogin feature lets admins log in with any account through a console command, which is the emergency access path when a migration goes wrong or a player is locked out.

The last piece in this group is the two-factor support, which is listed alongside Session Login in the feature list. Two factor on a Minecraft login is unusual, and for a server where accounts are valuable, whether the administrator enables it is the kind of decision that belongs in a security review rather than in a configuration file.

Graphical dialogs, premium bypass and the PacketEvents dependency

The Dialog UI section and the premium bypass section are the two places where the plugin touches the modern server APIs, and both have hard conditions that are stated clearly.

AuthMe can display graphical login and register dialogs instead of chat based prompts. There are two independent flows, controlled by configuration keys:

- `settings.registration.dialog.postJoin.enable` enables the **post-join** dialog flow.
- `settings.registration.dialog.preJoin.enable` enables the **pre-join** dialog flow on **Paper/Folia**.
- Both options are independent: you can enable either one, both, or neither.
- Pre-join dialogs currently require modern dialog-capable server versions such as **Paper/Folia 1.21.11+**.

The pre-join flow means the login dialog appears before the player is in the world at all, which is a better experience and a stronger protection, and it is the one with the version floor of Paper or Folia 1.21.11 and above. Verified premium players skip the pre-join dialog entirely when premium bypass is enabled.

Premium bypass itself lets players with a legitimate Mojang account skip password authentication. The README explains the mechanism, which is the part that matters for a security review: identity is verified through a cryptographic handshake with Mojang's session server during the Minecraft login phase, so no password prompt is ever shown. The player opts in with the /premium command and out with /freemium, and admins can enrol or remove players with the authme premium and authme freemium console commands.

The dependency is the part to note:

- Enable with `settings.enablePremium: true` in `config.yml`.
- Players opt in with `/premium` and out with `/freemium` (must be logged in). Admins can enrol or remove players with `/authme premium <player>` / `/authme freemium <player>`.
- **Direct-connection (offline-mode, no proxy):** requires [PacketEvents](https://github.com/retrooper/packetevents) 2.x. Without it, premium bypass is disabled at startup (fail-closed).

Fail-closed is the right default and it is worth reading twice. On a direct connection server with no proxy, PacketEvents 2.x is required, and without it the feature disables itself at startup rather than running in a degraded state where the handshake is skipped. Inventory protection has the same requirement. The behind-proxy case is described separately in the documentation.

A configuration file where every command can be switched off

The README makes two claims about configuration that are worth testing before you trust them.

The first is that each command and every feature can be enabled or disabled from a well structured configuration file, with the link to docs/config.md for the details. The second is that the configuration is extensible, and the dialog section shows the shape of that, with settings.registration.dialog.postJoin.enable and settings.registration.dialog.preJoin.enable as the keys.

The third is about messages. The plugin serves messages in each player's own Minecraft client language, with a server language fallback, and you can create your own translation file and share it. There is a translations document in the docs directory, and the available languages are listed as a feature.

Those three claims together describe a plugin that tries to be a platform rather than a script. The configuration keys are nested and namespaced by feature, the messages are externalised into translation files rather than compiled into the jar, and the feature switches are per command and per subsystem. For a server administrator who wants a login gate without twenty other behaviours, that is the difference between a plugin you can configure and one you can only tolerate.

The samples/ directory backs this up. It has a website_integration/ folder, which is the pattern for sharing the same user database with a website, and a databases/ folder, which suggests the database setup is documented by example rather than by prose alone. A server administrator evaluating this should read both, because the website integration case is where the plugin's design choices around caching and custom table names start to matter.

GPL-3.0, a 6.0 line, and four CI systems

The licence is GPL-3.0, with the LICENSE file at the repository root, which is the usual choice for a plugin that server administrators are encouraged to modify and redistribute.

The release line is 6.x. The recent releases are 6.0.1 on 2026-09-03, 6.0.0 on 2026-05-07 and 6.0.0-R1 on 2026-04-25, and the last push to the repository was on 2026-10-20. The presence of a release candidate tag alongside the final 6.0.0 suggests a release process that publishes a candidate first.

The build and test infrastructure is where a project of this age shows its history. The README carries badges for four systems: Code Climate for code quality, Coveralls for coverage status on the master branch, Jenkins hosted at ci.codemc.org with a build status and a tests badge, and Travis CI as the other CI. A Code Climate badge and a Jenkins badge side by side is a picture of a project that has been through a change of CI provider, and the presence of a .codeclimate.yml and a .checkstyle.xml at the root shows the static analysis side is configured rather than improvised.

The developer-facing files are in the same spirit. There is an .editorconfig, an .idea/ directory with the IDE configuration shared in the tree, and a pom.xml at the root, which is the Maven build file for the multi-module project, matching the multi-module directory layout.

For an administrator, the practical question about upgrading is which artifact you download and which config keys moved. A major version with breaking configuration changes is normal for a plugin at 6.0, and the docs directory in the repository is where that is written down.

Editorial conclusion

Adopt AuthMeReloaded if you run a Minecraft server in offline mode and need a real login layer, or if you are consolidating several older authentication plugins onto one supported build and want the built-in account importers to do the migration. Do not adopt it if your server runs in online mode and the premium bypass path is not available, because the plugin is built around the offline mode problem, and do not deploy the pre-join dialog flow on a server older than Paper or Folia 1.21.11, since that feature has a hard version floor. Before you deploy, read docs/config.md for the configuration keys, decide your backend and your hashing algorithm, and check which of the dedicated builds matches your server flavour, since Spigot Legacy, Spigot 1.21, Paper 1.21 and Folia 1.21 are separate artifacts.

Frequently asked questions

Official sources

1. AuthMe/AuthMeReloaded on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases