MariaDB Authentication Plugins: A Production Guide

Choosing among MariaDB authentication plugins affects far more than password syntax. The plugin determines how the server validates an identity, what the client connector must support, where credential policy lives, how local administration works, and what happens during a failed migration. A plugin can be cryptographically strong and still be the wrong production choice when application drivers cannot use it or operators have no tested recovery path.

This guide compares the main authentication models available to Linux administrators: unix_socket, mysql_native_password, ed25519, parsec, and PAM-backed authentication. It shows how to inspect actual account definitions, test connector compatibility, introduce a new method without locking out administrators, diagnose common failures, and roll back safely.

Examples target supported MariaDB releases, but availability is version-specific. In particular, PARSEC is available from MariaDB 11.6, while Ubuntu 24.04 distribution packages commonly use the MariaDB 10.11 family. Always run the discovery commands on the deployed server instead of assuming a plugin exists because it appears in current online documentation.

Separate authentication from authorization

Authentication answers, “Who is connecting, and how is that identity proved?” Authorization answers, “What may that account do?” MariaDB authentication plugins solve the first problem. Privileges, roles, object scope, and host matching solve the second.

An account remains the pair 'user'@'host' regardless of plugin:

'deploy'@'localhost'
'orders_api'@'10.20.30.25'

Two accounts with the same username but different hosts may use different plugins and grants. When a login behaves unexpectedly, inspect the account MariaDB actually matched:

SELECT USER() AS client_identity,
       CURRENT_USER() AS matched_account,
       CURRENT_ROLE() AS active_role;

Do not switch authentication plugins to repair a missing table grant. Conversely, adding SELECT does not repair a connector that cannot load the requested client authentication plugin.

Inventory server, accounts, and clients first

Before changing authentication, capture the server release and active plugin inventory:

mariadb --version
sudo mariadb -e "SELECT VERSION();"
sudo mariadb -e "SHOW PLUGINS;"

Narrow the output to authentication plugins:

SELECT PLUGIN_NAME, PLUGIN_STATUS, PLUGIN_TYPE, PLUGIN_LIBRARY
FROM information_schema.PLUGINS
WHERE PLUGIN_TYPE = 'AUTHENTICATION'
ORDER BY PLUGIN_NAME;

Inspect exact account definitions through supported statements:

SHOW CREATE USER 'root'@'localhost';
SHOW GRANTS FOR 'root'@'localhost';
SHOW CREATE USER 'orders_api'@'10.20.30.25';

On modern MariaDB, mysql.global_priv stores global account properties in JSON and mysql.user is a compatibility view. Avoid direct modifications to either. Use CREATE USER, ALTER USER, SET PASSWORD, GRANT, REVOKE, and DROP USER so the server maintains its own structures correctly.

The database inventory is only half the work. Record every connector and runtime:

• MariaDB command-line client version.
• Application driver name and exact version.
• Language runtime and operating system.
• Whether the connector ships its own authentication module.
• TLS mode and certificate verification behavior.
• Connection pool restart or reload procedure.
• Backup, monitoring, migration, and replication tools.
• Emergency administrative route.

A successful login with the mariadb CLI does not prove that PHP PDO, Java Connector/J, a Go driver, or a vendor appliance supports the same server plugin.

Compare the main authentication choices

The right design often uses more than one model. Local root administration may use unix_socket, applications may use a compatible password plugin over verified TLS, and human users may authenticate through PAM. Keep identities separate so one plugin decision does not widen every account.

Use unix_socket for controlled local identities

The unix_socket plugin authenticates a local connection using operating-system credentials obtained from the Unix socket. MariaDB checks the process identity rather than asking for a database password. It is installed by default in most MariaDB packages and commonly used for 'root'@'localhost'.

On Ubuntu, this command often works because the OS root identity is mapped to the MariaDB root account:

sudo mariadb --protocol=socket

Verify the matched identity:

SELECT USER(), CURRENT_USER();
SHOW CREATE USER 'root'@'localhost';

For a named local automation identity, first create a dedicated Linux account through your normal system-management process. Then create a matching MariaDB account:

CREATE USER 'dbhealth'@'localhost'
  IDENTIFIED VIA unix_socket;

GRANT SELECT
ON monitoring.health_view
TO 'dbhealth'@'localhost';

Test as that operating-system user:

sudo -u dbhealth mariadb 
  --protocol=socket 
  --user=dbhealth 
  --database=monitoring 
  --execute='SELECT * FROM health_view LIMIT 1;'

This is passwordless, not authentication-free. Its security boundary is the Linux user, privilege escalation controls, filesystem permissions, and access to the socket. Anyone who can run a process as dbhealth can use the MariaDB identity.

Do not use unix_socket for remote TCP clients. Do not map many people to one Unix account if individual attribution matters. Containers also complicate identity: a username or numeric UID inside a container may not represent the host identity you expect, and mounting the database socket into a container extends the local trust boundary.

Avoid locking out the local administrator

Before altering 'root'@'localhost', create and test a second named recovery administrator through an approved path. Keep one root session open during the change and test a completely new session. Existing sessions can remain usable even when new authentication is broken, so they are not sufficient proof.

Capture the original definition:

SHOW CREATE USER 'root'@'localhost';
SHOW GRANTS FOR 'root'@'localhost';

Do not replace socket authentication merely because an automation tool assumes a password. It is usually safer to create a separate narrowly scoped automation account than to weaken the local administrative identity.

Understand mysql_native_password compatibility

mysql_native_password is broadly supported by older and current connectors. MariaDB uses it by default for many password accounts when no alternative plugin is specified. It is based on the long-standing SHA-1 password-authentication design, so transport protection and credential quality remain important.

Create a conventional application account explicitly when compatibility requires it:

CREATE USER 'legacy_api'@'10.20.30.25'
  IDENTIFIED VIA mysql_native_password
  USING PASSWORD('replace-with-a-secret-manager-value');

Alternatively, standard IDENTIFIED BY syntax uses supported default password semantics for the release:

CREATE USER 'legacy_api'@'10.20.30.25'
  IDENTIFIED BY 'replace-with-a-secret-manager-value';

Never copy a production password into shell history, source control, a ticket, or a world-readable option file. Examples illustrate syntax only. Apply least-privilege grants separately and require verified TLS for TCP accounts.

The fact that mysql_native_password is compatible does not make it desirable for every new system. Use it when the connector matrix requires it, document that dependency, and plan a tested migration rather than attempting an unannounced global switch.

Never enable mysql_old_password for compatibility with obsolete clients. Upgrade or replace the client. Keeping an obsolete authentication method creates a permanent security exception around software that is already difficult to support.

Deploy ed25519 only after client validation

MariaDB's ed25519 plugin provides a stronger password-authentication design than the SHA-1-based native method. Its shared library is commonly distributed with MariaDB packages but is not necessarily installed in the server by default.

Check first:

SELECT PLUGIN_NAME, PLUGIN_STATUS, PLUGIN_LIBRARY
FROM information_schema.PLUGINS
WHERE PLUGIN_NAME = 'ed25519';

On a staging server, install the plugin dynamically if the matching package supplies it:

INSTALL SONAME 'auth_ed25519';

Confirm it is active and persists as expected after a controlled restart:

SHOW PLUGINS;

For configuration-managed startup loading, MariaDB also supports plugin_load_add = auth_ed25519 in an appropriate server option group. Choose one lifecycle and document it. Avoid a state where a plugin is installed dynamically but absent after rebuild, or configured twice without understanding package behavior.

Create a test account using the official syntax supported by the deployed release:

CREATE USER 'auth_test'@'10.20.30.90'
  IDENTIFIED VIA ed25519
  USING PASSWORD('temporary-test-secret');

Grant only a harmless validation capability or use the account with no object grants:

SHOW CREATE USER 'auth_test'@'10.20.30.90';
SHOW GRANTS FOR 'auth_test'@'10.20.30.90';

Test every production connector from its real runtime image. Some clients need a client_ed25519 plugin library that is not installed automatically. A client error about an authentication plugin can occur before password validation, so resetting the password does not fix it.

Delete the temporary account when compatibility testing ends:

DROP USER 'auth_test'@'10.20.30.90';

Do not uninstall auth_ed25519 while any account depends on it. Inventory account definitions and prove migration before removal.

Evaluate PARSEC with strict version gating

PARSEC is a modern MariaDB authentication plugin available from MariaDB 11.6. It uses salted password data, PBKDF2 parameters, and an elliptic-curve-based exchange designed to improve password storage and resist replay. MariaDB describes it as intended for a future default, but availability in server documentation does not imply support in an older server or every connector.

On a compatible test server:

SELECT VERSION();
SELECT PLUGIN_NAME, PLUGIN_STATUS, PLUGIN_LIBRARY
FROM information_schema.PLUGINS
WHERE PLUGIN_NAME = 'parsec';

If the release supplies the plugin but it is not loaded, the official installation syntax is:

INSTALL SONAME 'auth_parsec';

Create a compatibility-test account:

CREATE USER 'parsec_test'@'10.20.30.90'
  IDENTIFIED VIA parsec
  USING PASSWORD('temporary-test-secret');

If MariaDB 10.11 returns that the plugin is not loaded or the shared object is absent, that is not a configuration puzzle: the server predates PARSEC availability. Do not download a random binary plugin or force files from another release into the plugin directory. Upgrade through a supported MariaDB migration after validating the entire workload.

Client support is the gate. Test the exact connector build, not only the latest upstream driver documentation. Include connection pooling, password rotation, TLS verification, failover, and error handling. Keep a compatible administrative route while evaluating the plugin.

Use PAM for centralized human authentication

The PAM plugin delegates authentication to the operating system's Pluggable Authentication Modules framework on Unix-like servers. Depending on the PAM service, that may integrate local Unix passwords, LDAP, Active Directory, Kerberos-related components, time restrictions, or multi-factor mechanisms.

PAM is most attractive for named human accounts where centralized lifecycle and policy matter. It is usually a poor fit for high-volume application connection pools because authentication now depends on an external identity chain and interactive mechanisms may not suit service connections.

Check whether the plugin is active:

SELECT PLUGIN_NAME, PLUGIN_STATUS, PLUGIN_LIBRARY
FROM information_schema.PLUGINS
WHERE PLUGIN_NAME = 'pam';

The shared library may be packaged but not installed. On a staging server with the correct package:

INSTALL SONAME 'auth_pam';

A PAM service named mariadb is typically defined at /etc/pam.d/mariadb. Its exact contents depend on the identity provider and security policy. Do not paste an internet example over the system policy; have the Linux or identity team review control flags, modules, service account permissions, MFA behavior, and failure handling.

Create a MariaDB account referring to that service:

CREATE USER 'alice'@'10.20.30.%'
  IDENTIFIED VIA pam USING 'mariadb';

Then grant a database role independently:

GRANT reporting_readonly TO 'alice'@'10.20.30.%';
SET DEFAULT ROLE reporting_readonly FOR 'alice'@'10.20.30.%';

PAM client conversations may require the MariaDB dialog client plugin or connector-specific support. Validate clients before onboarding users. Protect TCP authentication with verified TLS, especially where a password or other sensitive response crosses the connection.

Keep a non-PAM local recovery route. If LDAP, DNS, network connectivity, time synchronization, PAM configuration, or an MFA provider fails, administrators still need a controlled way to diagnose MariaDB without bypassing policy informally.

Use multiple authentication methods as a migration tool

MariaDB 10.4 and later can define more than one authentication method for an account using OR. This can support a staged transition. For example, an account may retain a native-password method while clients move to ed25519:

ALTER USER 'orders_api'@'10.20.30.25'
  IDENTIFIED VIA ed25519 USING PASSWORD('new-secret')
  OR mysql_native_password USING PASSWORD('old-transition-secret');

Treat this as illustrative syntax and verify it on the exact release. Multiple methods expand the available authentication paths during transition, so set a deadline to remove the old one.

There is an important operational trap: when ALTER USER ... IDENTIFIED VIA is used, authentication methods omitted from the new clause can be removed on current releases. Before any alteration:

SHOW CREATE USER 'orders_api'@'10.20.30.25';

Copy the complete intended authentication definition into the reviewed change. Do not assume an omitted socket or fallback method will remain. Historical behavior also varied in older 10.4 patch releases, which is another reason to test the installed version.

A safe migration sequence is:

1. Inventory clients and capture the current account definition.
2. Create a new test account using the target plugin.
3. Validate every connector and operational workflow in staging.
4. Add the target method or create a parallel production account.
5. Move a small client cohort and verify new connections.
6. Drain old pooled sessions.
7. Remove the old method after the agreed observation window.
8. Confirm recovery accounts and restart persistence.
9. Delete temporary accounts and secrets.

For critical applications, a parallel account is often easier to observe and roll back than changing one account in place. It produces a new username, so deployment and grants must be managed carefully, but avoids ambiguity about which plugin an old connection used.

Test authentication correctly

Always test a new connection from the real client path. An existing pooled or interactive session says nothing about whether a new login succeeds.

For a TCP password account:

mariadb 
  --host=db01.example.net 
  --user=orders_api 
  --password 
  --ssl-ca=/etc/myapp/tls/mariadb-ca.pem 
  --ssl-verify-server-cert 
  --execute='SELECT USER(), CURRENT_USER();'

For a local socket account:

sudo -u dbhealth mariadb 
  --protocol=socket 
  --user=dbhealth 
  --execute='SELECT USER(), CURRENT_USER();'

Positive tests should prove the intended identity can connect. Negative tests should prove:

• The wrong OS user cannot use a socket-mapped account.
• An unauthorized source host cannot match the TCP account.
• A client without the required plugin fails.
• A wrong password fails.
• Plaintext fails when the account requires TLS.
• Authentication success does not grant unauthorized SQL privileges.

Record expected success or denial, but do not log secrets or fabricate terminal output.

Troubleshoot authentication plugin failures

ERROR 1524: Plugin is not loaded

Confirm the server version, plugin inventory, and package files:

SELECT VERSION();
SHOW PLUGINS;
SHOW VARIABLES LIKE 'plugin_dir';

dpkg -L mariadb-server 2>/dev/null | grep -E 'auth_(ed25519|pam|parsec)' || true

Install only the plugin shipped for the exact server package. A missing PARSEC library on MariaDB 10.11 is expected because PARSEC begins with 11.6.

Client reports an unknown authentication plugin

The server plugin is active, but the connector cannot complete the client side of the protocol. Check driver version and authentication-module packaging. Reproduce with the same runtime image. Upgrading the CLI on the database host does not upgrade the application connector.

Access denied after ALTER USER

Use a separate tested administrator session to inspect:

SHOW CREATE USER 'orders_api'@'10.20.30.25';
SHOW GRANTS FOR 'orders_api'@'10.20.30.25';

Check whether an authentication method was accidentally omitted, the wrong 'user'@'host' account was altered, the password was encoded with syntax inappropriate for the plugin, or the application still uses an old secret in its pool.

sudo mariadb no longer works

Verify that the connection uses the Unix socket, the OS process is root, and 'root'@'localhost' still includes unix_socket authentication. Do not repeatedly run mariadb-secure-installation as a repair. Use the planned recovery route and restore the captured account definition through supported SQL.

unix_socket works for one service but not another

Inspect the actual process UID and socket path:

id dbhealth
sudo -u dbhealth id
sudo mariadb -NBe "SHOW VARIABLES LIKE 'socket';"

The service may run under a different systemd User=, container UID, or socket namespace than expected. Fix the identity model rather than granting database root access.

PAM succeeds on the host but fails through MariaDB

Test the named PAM service with approved diagnostic tools, inspect authentication logs without exposing credentials, and verify that MariaDB can access required PAM modules or helper processes. Check the client dialog-plugin support and TLS. PAM stack ordering and control flags can change behavior even when the identity provider itself is healthy.

Authentication works but SQL is denied

That is authorization, not plugin failure. Run:

SELECT USER(), CURRENT_USER(), CURRENT_ROLE();
SHOW GRANTS;

Repair the least-privilege role or object grant without changing authentication.

Operational best practices

• Maintain a tested local recovery administrator independent of external identity providers.
• Use SHOW CREATE USER before and after every authentication change.
• Test exact server, connector, runtime, and operating-system versions.
• Protect every TCP authentication method with verified TLS.
• Keep runtime, migration, monitoring, backup, and human identities separate.
• Never edit mysql.global_priv or mysql.user directly.
• Load plugins through a documented, restart-persistent lifecycle.
• Do not uninstall a plugin while any account references it.
• Treat multiple methods as a temporary migration state, not permanent convenience.
• Rotate test credentials and delete compatibility accounts after validation.
• Monitor login failures while protecting usernames, network details, and secrets.
• Re-test authentication after driver upgrades, server upgrades, container rebuilds, and failover changes.

FAQ

Which MariaDB authentication plugin is best?

There is no universal choice. Use unix_socket for controlled local identities, a connector-compatible modern password method for applications, and PAM where centralized human identity is operationally supported.

Why does sudo mariadb work without a password?

Many Linux packages configure 'root'@'localhost' with unix_socket, which verifies the operating-system root identity over the local socket.

Is mysql_native_password still supported by MariaDB?

It remains widely supported, but uses an older SHA-1-based design. Use strong secrets, verified TLS, least privilege, and a documented compatibility rationale.

Can MariaDB accounts use two authentication plugins?

MariaDB 10.4 and later can define multiple methods with OR. This is useful for staged migration, but omitted methods in a later ALTER USER can be removed.

Why is PARSEC unavailable on Ubuntu 24.04 MariaDB?

Ubuntu 24.04 commonly ships MariaDB 10.11, while PARSEC is available from MariaDB 11.6. It requires a supported server upgrade and compatible clients.

Must ed25519 be installed separately?

The shared library is often included with MariaDB packages, but the server plugin is not necessarily installed by default. Check SHOW PLUGINS before creating accounts that depend on it.

Is unix_socket authentication safe for containers?

Only when socket sharing and UID identity are deliberately controlled. Mounting the database socket into a container expands the local trust boundary and can create unexpected identity matches.

Should application accounts use PAM?

Usually not. PAM is often better for named human access. High-volume services benefit from a noninteractive, well-supported method with a predictable secret and connector lifecycle.

Conclusion

Production use of MariaDB authentication plugins starts with compatibility and recovery, not with a one-line ALTER USER. Inventory every server and connector, separate local, application, and human identities, then test the target plugin through new connections from real runtime environments.

Use unix_socket where the operating-system identity is the intended trust anchor, modern password plugins only where the full connector fleet supports them, and PAM when the external identity chain has clear ownership. Preserve a tested recovery account, capture complete account definitions, and remove transitional methods promptly. That combination improves authentication without trading security for an avoidable lockout.

Suggested Internal Links

• Secure a New MariaDB Server: Production Hardening Guide
• MariaDB Users and Grants: A Least-Privilege Production Guide
• Configure MariaDB TLS for Secure Client Connections
• Harden MariaDB Against SQL Injection and Credential Leaks
• Audit MariaDB Users, Privileges, and Security Events
• Troubleshoot MariaDB Connection Refused and Access Denied

Suggested External Sources

• MariaDB pluggable authentication overview
• MariaDB authentication from 10.4
• MariaDB ALTER USER documentation
• MariaDB Unix socket authentication
• MariaDB ed25519 authentication
• MariaDB PARSEC authentication
• MariaDB PAM authentication
• MariaDB mysql.global_priv table