Skip to content
jack edited this page Jun 25, 2026 · 13 revisions

The Wawel Auth client module provides account management, per-server account binding, and client-side skin rendering improvements. List of the latter:

  • Modern skin format support
  • HD skin/cape support
  • Animated cape support (exclusively for Wawel Auth local accounts)
  • 3D Skin Layers

It allows to keep multiple accounts, connect to multiple auth providers simultaneously, and render modern skins, animated capes, and 3D skin layers.

image

Note

Besides UniMixins and FentLib, client Wawel Auth also depends on ModularUI2.

image The account manager can be opened from the `Auth` button in the multiplayer screen. A keybind is also available, but is unbound by default.

Tip

On modern Java, skin and cape files can be dragged and dropped.

image

Providers

Built-in providers available by default:

  • Microsoft
  • Ely.by
  • LittleSkin
  • Offline

These entries cannot be removed from the account manager, but a proxy can be configured for each of them. Remote built-in provider definitions are seeded to default-providers/*.json in the active client data config directory (microsoft.json, elyby.json, littleskin.json). With shared client data enabled, this directory is shared between instances. If local.json sets useOsConfigDir=false, it lives under config/wawelauth/default-providers/ instead. Edit those files and restart the client to change auth/session/services endpoints, Microsoft login endpoints, skin domains, or provider public keys. This is mainly useful if a future provider-side endpoint change needs to be handled before a Wawel Auth update is available.

image

Microsoft only supports OAuth login. Ely.by and LittleSkin support username/password login, and OAuth as well.

image

Any Yggdrasil / authlib-injector provider can also be added manually by URL.

If a server advertises local Wawel Auth support, the Manage Local Auth... button opens the regular account manager focused on that server's local provider. Trust & Refresh trusts the server's advertised auth key and updates saved provider metadata after the server changes address, certificate, or public provider information. Local providers also expose their public key fingerprint, which can be verified against a fingerprint published by the server owner through a trusted channel. The same server can also be added manually as a normal provider if desired.

Accounts

Each provider can store any amount of accounts.

Offline is a special built-in provider. It does not authenticate against a remote service, and uses the vanilla offline UUID for the chosen name. A skin and cape can still be set for it.

Launcher session import

On startup, Wawel Auth can detect the account supplied by the launcher and offer to import it into the account manager.

Imported launcher accounts only contain the current launcher access token. They cannot be refreshed by Wawel Auth because the launcher does not provide a refresh token to the mod. When the launcher issues a new usable session later, Wawel Auth can re-sync the imported account from that session.

Choosing Don't ask again for a detected launcher account stores that suppression in launcher_import_suppression.json.

Per-server account bindings

Wawel Auth can remember which account should be used for a specific multiplayer server entry.

These bindings are stored with the server entry itself, so different servers can automatically use different accounts. If no explicit binding exists and the server advertises exactly one matching provider among the saved accounts, Wawel Auth will auto-choose that account for that connection without saving a permanent binding.

Stale bindings are cleaned automatically if the linked account no longer exists.

To bind an account to a server, manage local accounts (if applicable), or set a server proxy, use the little castle icon for the target server. Shift-clicking the castle on a Wawel Auth-enabled server jumps directly to that server's local provider in the regular account manager: image

image

By default, accounts and most of the client configuration live in a folder outside of the Minecraft installation, shared between all instances. The shared folder can be opened with this button: image

Files and configuration

Shared folder locations per OS:

  • Linux: $XDG_DATA_HOME/wawelauth/ or ~/.local/share/wawelauth/
  • macOS: ~/Library/Application Support/wawelauth/
  • Windows: %APPDATA%/wawelauth/

A minimal set of settings that make sense to be kept local can be found in config/wawelauth/.

If local.json sets useOsConfigDir=false, all client data is kept locally.

The main client-side files are:

  • local.json (local, as name implies)
  • default-providers/*.json (shared by default)
  • accounts.db (shared by default)
  • launcher_import_suppression.json (shared by default)
  • config/wawelauth/wawelauth.cfg (local Minecraft config)

local.json

Contains the following fields:

  • debugMode: enables verbose client-side logging.
  • useOsConfigDir

config/wawelauth/wawelauth.cfg

Client UI and rendering options are stored in config/wawelauth/wawelauth.cfg.

The client category controls account manager provider defaults and cosmetic provider action restrictions:

  • defaultProvider
  • disableSkinUpload
  • disableCapeUpload
  • disableTextureReset
  • disableCredentials

defaultProvider is the name of the auth provider auto-selected when no provider is already selected.

The disable* fields are regex lists matched against provider name or API root. They are meant to hide provider actions that are known not to work cleanly. These are cosmetic UI restrictions, not hard security rules.

disableCredentials hides the credential management button for matching providers. By default it matches Mojang, Ely.by, and LittleSkin.

The skinlayers and skinlayers3D categories control flat overlay toggles, 3D skin layer toggles, per-part 3D enable flags, render distance, and voxel sizing.

accounts.db

accounts.db is the client's SQLite database.

It stores saved providers and saved accounts.

Clone this wiki locally