FastLogin: letting premium Minecraft players skip the password prompt

The problem is that offline mode has no way to ask Mojang who you are

The premise is stated in two sentences at the top of the README. FastLogin checks if a Minecraft player has a paid account, and if so they can skip offline authentication, so they do not need to enter passwords. This is also called auto login.

That situation only arises on servers running in offline mode, which is the standard for networks that want to allow both paying and non-paying players. In offline mode the server accepts whatever name a client claims, and a separate auth plugin, the README calls for an auth plugin as a requirement, is what asks for a password. Every player, including the ones with a legitimate paid Mojang account, has to go through that plugin and type a password on every connection.

FastLogin's job is to remove that step for players who genuinely own the account. The feature list spells out the pieces: detect paid accounts from others, automatically log in paid accounts, support various auth plugins, premium UUID support, forward skins, detect username changed and will update the existing database record, BungeeCord and Velocity support, auto register new premium players, no client modifications needed, good performance by using async operations, locale messages, and support for Bedrock players through FloodGate.

Two of those are worth pausing on. Premium UUID support matters because a player who joins as premium gets the same UUID as they do on the official servers, which is what stops inventories, permissions and statistics from being split across two identities. And no client modifications needed is the point of the whole design, since the alternative approach of asking players to install something would defeat the purpose.

Forward skins and username change detection are smaller features with a similar motivation, keeping a player's identity consistent across the network rather than letting the same person accumulate two records.

The login sequence is a handshake with Mojang, not with the player

The README includes a sequence diagram of the technical authentication flow, and it is the clearest explanation of what the plugin does.

The flow starts with the client sending LOGIN_START with a name to the server. The server checks its database to see whether that username is saved as premium. It then sends ENCRYPTION_REQUEST to the client, and the diagram notes two things at that point: offline clients terminate the connection here, and in offline mode LOGIN_SUCCESS is sent directly.

For a premium client, the interesting part follows. The client posts to the Mojang session endpoint at /session/minecraft/join and then sends ENCRYPTION_RESPONSE to the server, and the client starts encrypting. The server decrypts and verifies the token, and then makes an asynchronous GET to the /hasJoined endpoint. Mojang replies with a uuid, a name and a skin.

The server then encrypts traffic, injects the skin and the premium UUID, re-injects LOGIN_START with the name, and finally sends LOGIN_SUCCESS to the client.

Two mechanics in that flow are the whole design. The client talks to Mojang directly, so the server never sees the player's Mojang password, and the server's own call to /hasJoined is what proves the session is real, because Mojang only answers yes for a session key that Mojang itself issued for that name. The re-injection of LOGIN_START is what lets the plugin rewrite the identity and the skin on the way through, after encryption has already been established.

The requests go to two different hosts, and the README lists them explicitly. The plugin performs network requests to https://api.mojang.com for retrieving uuid data to decide whether premium login should be activated, and to https://sessionserver.mojang.com to verify that the player is the owner of that account.

The proxy setup is where the configuration actually lives

Installation on Spigot or Paper is three steps: download and install ProtocolLib or ProtocolSupport, download and install FastLoginBukkit, and set your server to offline mode by setting the value `onlinemode` in your server.properties to `false`.

The proxy path is longer, and the README is explicit that the plugin has to be installed on both platforms, that is the proxy and the backend server. The steps then cover activating proxy support in the server configuration, which is often found in `spigot.yml` or `paper.yml`, and restarting the backend server.

After the restart there is an `allowed-proxies.txt` file in the FastLogin folder of the backend server. For BungeeCord you put your `stats`-id from the BungeeCord config into that file. For Velocity, the plugin generates a `proxyId.txt` inside the plugins folder of the proxy on startup. Then you activate ip forwarding in the proxy config, check the database settings in the FastLogin config on the proxy, and set both proxy and Spigot to offline mode by setting `onlinemode` to false in the config.

The database step is where a proxy deployment quietly breaks. The README explains that the proxies only ship with a limited set of drivers where Spigot supports more. BungeeCord supports `mysql` for MySQL and MariaDB, Velocity supports `mariadb`, and the embedded file storage SQLite is not available. MySQL and MariaDB require an external database server running, so you have to check your server provider for one or install one.

The final step is the one that is easy to skip and expensive to get wrong. The README says you should always configure the firewall for your Spigot server so that it is only accessible through your proxy, and notes that this is also the case without this plugin, with a link to the BungeeCord installation wiki.

The requirements list reads like a compatibility matrix

The Requirements section is precise, and every line of it is a decision you might otherwise discover at runtime.

Java 21 or newer is recommended, and the wording is specific about why: for improved multi-threading code by FastLogin. For Spigot that means 8 or newer, and for BungeeCord and Velocity it means 17 or newer. The server software must be in offline mode, and for Spigot or a fork such as Paper that means 1.8.8 or newer, with either ProtocolLib 5.3 or newer using a development build above 720, or ProtocolSupport. The proxy must be the latest BungeeCord or a fork such as Waterfall, or Velocity. And an auth plugin is required.

The auth plugin list is long and split by platform, which tells you how varied the ecosystem is. On Spigot and Paper there are AdvancedLogin, which is marked as paid, AuthMe 5.X, CrazyLogin, LoginSecurity, LogIt, UltraAuth, UserLogin and xAuth. On BungeeCord and Waterfall there is BungeeAuth.

The 1.8.8 floor is a bit surprising if you are only used to modern Minecraft servers, and it is there because the login protocol this plugin intercepts has to work with the older client versions that a mixed network still has to accommodate. That is also why the protocol plugin is a hard requirement rather than a convenience, since the plugin has to manipulate the login packets themselves.

For the Bedrock side, the feature list says it supports Bedrock players through FloodGate, which is the separate bridge for Geyser-era Bedrock clients. Nothing in the visible documentation explains how that interacts with the premium detection, so a FloodGate deployment deserves its own testing.

Commands, permissions and a placeholder with a known lag

The user-facing surface is small, which is appropriate for a plugin that sits in the login path.

There are two commands. `/premium [player]` labels the invoker or the argument as a paid account, and `/cracked [player]` labels the invoker or the argument as a cracked account. The optional argument is what lets an administrator correct the plugin's own detection for a specific player, which matters when a premium player is behind a connection the plugin cannot resolve, or when a cracked player happens to own an account with the same name.

The permissions mirror the two commands in two tiers. `fastlogin.bukkit.command.premium` and `fastlogin.bukkit.command.cracked` cover the invoker, and `fastlogin.command.premium.other` and `fastlogin.command.cracked.other` cover acting on another player.

The placeholder is the part with a documented sharp edge. The plugin supports PlaceholderAPI on Spigot and exports `%fastlogin_status%`, with the possible values `Premium`, `Cracked` and `Unknown`. The README is candid that in BungeeCord environments the status of a player will be delivered with a delay after the player already successfully joined the server, that this takes about a couple of milliseconds, and that in this case the value will be `Unknown`.

So a scoreboard or hologram reading that placeholder will briefly show Unknown for a player who has just joined. That is a small detail, but it is exactly the sort of thing that shows up as a flicker in a scoreboard, and the README tells you to expect it rather than leaving you to find it.

Compared with a strict online-mode server and with per-player manual labelling

The alternatives are worth setting out, because the choice of FastLogin over them is really a choice about what kind of network you run.

A strict online-mode server accepts only paying players, and it is the simplest possible answer: no plugin, no auth plugin, no proxy split. The cost is that non-paying players are excluded, and the network loses them. For a server that is monetized or that wants a curated community, that is often the right answer and FastLogin is unnecessary.

A cracked-only network runs offline mode with an auth plugin for everybody, which is the situation FastLogin improves on. Here the plugin's value is proportional to how many of your players actually pay, since each paying player it spares the password prompt is a small quality-of-life gain for them and nothing at all for the rest.

The third alternative is to do nothing but label accounts manually, which is what the `/premium` and `/cracked` commands amount to. For a small server with a handful of paying players on a shared account or a friend group, that is often sufficient and carries no configuration risk. FastLogin is the automated version of that manual process, and it earns its keep when the number of paying players is large enough that hand-labelling becomes a support burden.

There is a fourth option worth naming for anyone on a network with a proxy: solving the problem with the proxy's own forwarding configuration and premium handling. Some networks do this without any plugin, at the cost of losing the per-player labelling, the skin forwarding and the auth plugin integration that the feature list describes.

The maintenance picture is the part to weigh honestly. The listed releases are a temporary download for 1.12 with a kick toggle dated 2025-04-28, FastLogin v1.11 Legacy from 2022-12-22, and a TCPShield workaround from 2022-04-10. The last push was on 2026-05-05 and the project is not archived, so work is happening, but the tagged history is irregular, and a plugin in the login path is the last thing you want to be running unattended for a year.

Editorial conclusion

Adopt FastLogin if you run an offline-mode Minecraft server and want paying players to connect without a password while cracked accounts still use your auth plugin. Do not adopt it if your server is in online mode already, since the plugin exists to bridge the offline-mode gap, and treat the proxy configuration as the real work rather than the install. Verify first that your server software and auth plugin are on the supported list, that Java 21 or newer is available, and that the firewall rule keeping the backend server reachable only through the proxy is actually in place.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. TuxCoding/FastLogin on GitHub