Pluggable authentication allows MariaDB to use various authentication methods, enabling external validation, different hashing algorithms, and role-based access control.
When a user attempts to log in, the authentication plugin controls how MariaDB Server determines whether the connection is from a legitimate user.
When creating or altering a user account with the GRANT, CREATE USER or ALTER USER statements, you can specify the authentication plugin you want the user account to use, by providing the IDENTIFIED VIA clause. By default, when you create a user account without specifying an authentication plugin, MariaDB uses the mysql_native_password plugin.
You can specify multiple authentication plugins for each user account.
The root@localhost user created by has the ability to use two authentication plugins:
It is configured to try to use the authentication plugin. This allows the root@localhost user to log in without a password via the local Unix socket file defined by the system variable, as long as the login is attempted from a process owned by the operating system root user account.
If authentication fails with the authentication plugin, it is configured to try to use the authentication plugin. However, an invalid password is initially set, so in order to authenticate this way, a password must be set with .
The authentication process is a conversation between the server and a client. MariaDB implements both server-side and client-side authentication plugins.
MariaDB provides seven server-side authentication plugins:
MariaDB provides eight client-side authentication plugins:
MariaDB supports the following server options related to authentication plugins:
Most support command-line arguments related to client authentication plugins:
Developers who are using can implement similar functionality in their application by setting the following options with the function:
MYSQL_OPT_CAN_HANDLE_EXPIRED_PASSWORDS
MYSQL_PLUGIN_DIR
MYSQL_DEFAULT_AUTH
For example:
supports the following installation options related to authentication plugins:
MariaDB has extended the SQL standard , , and statements, so that they support specifying different authentication plugins for specific users. An authentication plugin can be specified with these statements by providing the IDENTIFIED VIA clause. Examples:
The optional USING clause allows users to provide an authentication string to a plugin. The authentication string's format and meaning is completely defined by the plugin.
For example, for the authentication plugin, the authentication string should be a password hash:
Since is the default authentication plugin, the above is just another way of saying the following:
In contrast, for the authentication plugin, the authentication string should refer to a :
A user account can be associated with multiple authentication plugins.
To configure the root@localhost user account to try the authentication plugin, followed by the authentication plugin as a backup, execute the following query:
See for more information.
Not all server-side authentication plugins are installed by default. If a specific server-side authentication plugin is not installed by default, then you can find the installation procedure on the documentation page for the specific authentication plugin.
The following server-side authentication plugins are installed by default:
The and authentication plugins authentication plugins are installed by default in all builds.
The authentication plugin is installed by default in all builds on Unix and Linux.
The authentication plugin is installed by default in all builds on Windows.
The following server-side authentication plugins are installed by default:
The and authentication plugins are installed by default in all builds.
The authentication plugin is installed by default in new installations that use the packages provided by Debian's default repositories and Ubuntu's default repositories in Ubuntu. See for more information.
The authentication plugin is installed by default in all builds on Windows.
Client-side authentication plugins do not need to be installed in the same way that server-side authentication plugins do. If the client uses either the libmysqlclient or library, then the library automatically loads client-side authentication plugins from the library's plugin directory whenever they are needed.
Most support the --plugin-dir command line argument that can be used to set the path to the library's plugin directory:
Developers who are using can implement similar functionality in their application by setting the MYSQL_PLUGIN_DIR option with the function. Example:
If your client encounters errors similar to the following error, you may need to set the path to the library's plugin directory:
If the client does not use either the libmysqlclient or library, then you will have to determine which authentication plugins are supported by the specific client library used by the client.
If the client uses either the libmysqlclient or library, but the client is not bundled with either library's optional client authentication plugins, then you can only use the conventional authentication plugins (like and ) and the non-conventional authentication plugins that don't require special client-side authentication plugins (like and ).
The authentication plugin is currently the default authentication plugin in all versions of MariaDB if the system variable is set to 0, which is the default.
On a system with the system variable set to 0, this means that if you create a user account with either the or statements, and if you do not specify an authentication plugin with theIDENTIFIED VIAclause, then MariaDB will use the [mysql_native_password](authentication-plugin-mysql_native_password.md) authentication plugin for the user account.
Creating a user account like this, it uses the authentication plugin:
The same is true for this user account:
The authentication plugin becomes the default authentication plugin in all versions of MariaDB, if the system variable is explicitly set to 1.
The authentication plugin is not considered secure. It is recommended to avoid using this authentication plugin. To help prevent undesired use of the authentication plugin, the server supports the system variable that configures the server to refuse connections trying to use the authentication plugin.
Most support secure_auth.
Developers using can implement similar functionality in their application by setting the MYSQL_SECURE_AUTH option with the function:
The default client-side authentication plugin depends on these factors:
If a client doesn't explicitly set the default client-side authentication plugin, the client determines which authentication plugin to use, by checking the length of the scramble in the server's handshake packet.
If the server's handshake packet contains a 9-byte scramble, the client defaults to the authentication plugin.
If the server's handshake packet contains a 20-byte scramble, the client defaults to the authentication plugin.
Most support the --default-auth command-line argument that sets the default client-side authentication plugin:
Developers using can implement similar functionality in applications, by setting the MYSQL_DEFAULT_AUTH option with the function:
If you know that your user account is configured to require a client-side authentication plugin other than or , this helps speed up your connection process when you explicitly set the default client-side authentication plugin.
According to the , the server first sends the handshake packet to the client, then the client replies with a packet containing the user name of the user account that is requesting access. The server handshake packet initially tells the client to use the default server authentication plugin, and the client reply initially tells the server that it will use the default client authentication plugin.
However, the server-side and client-side authentication plugins mentioned in these initial packets may not be the correct ones for this specific user account. The server only knows what authentication plugin to use for this specific user account after reading the user name from the client reply packet and finding the appropriate row for the user account in either the table or the table, depending on the MariaDB version.
If the server finds that either the server-side or client-side default authentication plugin does not match the actual authentication plugin that should be used for the given user account, then the server restarts the authentication on either the server side or the client side.
This means that, if you know what client authentication plugin your user account requires, then you can avoid an unnecessary authentication restart and you can save two packets and two round-trips.between the client and server by configuring your client to use the correct authentication plugin by default.
mysql_native_passwordThe authentication plugin uses the same password hashing algorithm used by the function when is set. This hashing algorithm is based on .
mysql_old_passwordThe authentication plugin uses the same hashing algorithm used by the function and by the function when is set.
ed25519The authentication plugin uses the to securely store users' passwords and to authenticate users. The algorithm is the same one that is . It is based on the elliptic curve and code created by .
gssapiThe authentication plugin allows authenticating with services that use the . Windows has a slightly different but very similar API called .
On Windows, this authentication plugin supports and authentication. Windows authentication is supported regardless of whether a is used in the environment.
On Unix systems, the most dominant GSSAPI service is . However, it is less commonly used on Unix systems than it is on Windows. Regardless, this authentication plugin also supports Kerberos authentication on Unix.
The authentication plugin is most often used for authenticating with .
pamThe authentication plugin allows MariaDB to offload user authentication to the system's framework. PAM is an authentication framework used by Linux, FreeBSD, Solaris, and other Unix-like operating systems.
unix_socketThe authentication plugin allows the user to use operating system credentials when connecting to MariaDB via the local Unix socket file. This Unix socket file is defined by the system variable.
The authentication plugin works by calling the system call with the SO_PEERCRED socket option, which allows it to retrieve the uid of the process that is connected to the socket. It is then able to get the user name associated with that uid. Once it has the user name, it will authenticate the connecting user as the MariaDB account that has the same user name.
For example:
In this example, a user serg is already logged into the operating system and has full shell access. The user has already authenticated with the operating system and the MariaDB account is configured to use the authentication plugin, so the user does not need to authenticate again for the database. MariaDB accepts the user's operating system credentials and allows connecting. However, any attempt to connect to the database as another operating system user will be denied.
named_pipeThe authentication plugin allows the user to use operating system credentials when connecting to MariaDB via named pipe on Windows. Named pipe connections are enabled by the system variable.
The authentication plugin works by using and calling GetUserName() to retrieve the user name of the process that is connected to the named pipe. Once it has the user name, it authenticates the connecting user as the MariaDB account that has the same user name:
The authentication plugin API is extensively documented in the in the following files:
mysql/plugin_auth.h (server part)
mysql/client_plugin.h (client part)
mysql/plugin_auth_common.h (common parts)
The MariaDB also contains some authentication plugins that are intended explicitly to be examples for developers. They are located in plugin/auth_examples.
The definitions of two example authentication plugins called two_questions and three_attempts can be seen in plugin/auth_examples/dialog_examples.c. These authentication plugins demonstrate how to communicate with the user using the client authentication plugin.
The two_questions authentication plugin asks the user for a password and a confirmation ("Are you sure?").
The three_attempts authentication plugin gives the user three attempts to enter a correct password.
The password for both of these plugins should be specified in the plain text in the USING clause:
The client authentication plugin, strictly speaking, is not part of the client-server or authentication plugin API. But it can be loaded into any client application that uses the libmysqlclient or libraries. This authentication plugin provides a way for the application to customize the UI of the dialog function.
In order to use the client authentication plugin to communicate with the user in a customized way, the application will need to implement a function with the following signature:
The function takes the following arguments:
The connection handle.
A question "type", which has one of the following values:
1 - Normal question
2
The function returns a pointer to a string of characters, as entered by the user. It may be stored in buf or allocated with malloc().
By using this function, a GUI application can open a dialog window, and a network application can send the question over the network, as required. If no mysql_authentication_dialog_ask function is provided by the application, the client authentication plugin falls back to and .
Providing this callback is particularly important on Windows, because Windows GUI applications have no associated console and the default dialog function will not be able to reach the user. An example of Windows GUI client that does it correctly is .
This page is licensed: CC BY-SA / Gnu FDL
unix_socket (Unix only)
named_pipe (Windows only)
MYSQL_SECURE_AUTHA prompt.
A buffer.
The length of the buffer.
If set to 1 (0 is default), MariaDB reverts to using the mysql_old_password authentication plugin by default for newly created users and passwords, instead of the mysql_native_password authentication plugin.
Path to the plugin directory. For security reasons, either make sure this directory can only be read by the server, or set secure_file_priv.
The lowest acceptable plugin maturity. MariaDB will not load plugins less mature than the specified level.
Connections will be blocked if they use the mysql_old_password authentication plugin.
--connect-expired-password
Notify the server that this client is prepared to handle expired password sandbox mode even if --batch was specified.
--default-auth=name
Default authentication client-side plugin to use.
--plugin-dir=path
Directory for client-side plugins.
--secure-auth
Refuse to connect to the server if the server uses the mysql_old_password authentication plugin. This mode is off by default, which is different from MySQL.
--auth-root-authentication-method={normal | socket}
If set to normal (the default), it creates a root@localhost account that authenticates with the mysql_native_password authentication plugin and that has no initial password set, which can be insecure. If set to socket, it creates a root@localhost account that authenticates with the unix_socket authentication plugin. Set to normal by default.
--auth-root-socket-user=USER
Used with --auth-root-authentication-method=socket. It specifies the name of the second account to create with SUPER privileges in addition to root, as well as of the system account allowed to access it. Defaults to the value of --user.
--plugin-dir=path
Directory for client-side plugins.
If set to 1 (0 is default), MariaDB reverts to using the mysql_old_password authentication plugin by default for newly created users and passwords, instead of the mysql_native_password authentication plugin.
Connections are blocked if they use the mysql_old_password authentication plugin.
--default-auth=name
Default authentication client-side plugin to use.
mysql_optionsv(mysql, MYSQL_OPT_CAN_HANDLE_EXPIRED_PASSWORDS, 1);
mysql_optionsv(mysql, MYSQL_DEFAULT_AUTH, "name");
mysql_optionsv(mysql, MYSQL_PLUGIN_DIR, "path");
mysql_optionsv(mysql, MYSQL_SECURE_AUTH, 1);GRANT <privileges> ON <level> TO <user>
IDENTIFIED VIA <plugin> [ USING <string> ]CREATE USER <user>
IDENTIFIED VIA <plugin> [ USING <string> ]ALTER USER <user>
IDENTIFIED VIA <plugin> [ USING <string> ]CREATE USER mysqltest_up1
IDENTIFIED VIA mysql_native_password USING '*E8D46CE25265E545D225A8A6F1BAF642FEBEE5CB';CREATE USER mysqltest_up1
IDENTIFIED BY PASSWORD '*E8D46CE25265E545D225A8A6F1BAF642FEBEE5CB';CREATE USER mysqltest_up1
IDENTIFIED VIA pam USING 'mariadb';CREATE USER root@localhost
IDENTIFIED VIA unix_socket
OR mysql_native_password USING PASSWORD("verysecret");mysql_optionsv(mysql, MYSQL_PLUGIN_DIR, "path");ERROR 2059 (HY000): Authentication plugin 'dialog' cannot be loaded: /usr/lib/mysql/plugin/dialog.so: cannot open shared object file: No such file or directoryCREATE USER username@hostname;CREATE USER username@hostname IDENTIFIED BY 'notagoodpassword';mysql_optionsv(mysql, MYSQL_SECURE_AUTH, 1);mysql_optionsv(mysql, MYSQL_DEFAULT_AUTH, "name");$ mysql -uroot
MariaDB []> CREATE USER serg IDENTIFIED VIA unix_socket;
MariaDB []> CREATE USER monty IDENTIFIED VIA unix_socket;
MariaDB []> quit
Bye
$ whoami
serg
$ mysql --user=serg
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 2
Server version: 5.2.0-MariaDB-alpha-debug Source distribution
MariaDB []> quit
Bye
$ mysql --user=monty
ERROR 1045 (28000): Access denied for user 'monty'@'localhost' (using password: NO)CREATE USER wlad IDENTIFIED VIA named_pipe;
CREATE USER monty IDENTIFIED VIA named_pipe;
quit
C:\>echo %USERNAME%
wlad
C:\> mysql --user=wlad --protocol=PIPE
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 4
Server version: 10.1.12-MariaDB-debug Source distribution
Copyright (c) 2000, 2015, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> quit
Bye
C:\> mysql --user=monty --protocol=PIPE
ERROR 1698 (28000): Access denied for user 'monty'@'localhost'CREATE USER insecure IDENTIFIED VIA two_questions USING 'notverysecret';extern "C" char *mysql_authentication_dialog_ask(
MYSQL *mysql, int type, const char *prompt, char *buf, int buf_len)