When a client connects to the MySQL server, the server uses the
user name provided by the client and the client host to select the
appropriate account row from the
table. The server then authenticates the client, determining from
the account row which authentication plugin applies for the
If the account row specifies a plugin, the server invokes it to authenticate the user. If the server cannot find the plugin, an error occurs.
If the account row specifies no plugin name, the server
authenticates the account using either the
mysql_old_password plugin, depending on
whether the password hash value in the
Password column used native hashing or the
older pre-4.1 hashing method. Clients must match the password
Password column of the account row.
As of MySQL 5.7.2, the server requires the plugin value to be
nonempty, and as of 5.7.5, support for
mysql_old_password is removed.
The plugin returns a status to the server indicating whether the user is permitted to connect.
Pluggable authentication enables two important capabilities:
Pluggable authentication makes it possible for clients to
connect to the MySQL server with credentials that are
appropriate for authentication methods other than native
authentication based on passwords stored in the
mysql.user table. For example, plugins can
be created to use external authentication methods such as PAM,
Windows login IDs, LDAP, or Kerberos.
Proxy users: If a user is permitted to connect, an authentication plugin can return to the server a user name different from the name of the connecting user, to indicate that the connecting user is a proxy for another user. While the connection lasts, the proxy user is treated, for purposes of access control, as having the privileges of a different user. In effect, one user impersonates another. For more information, see Section 5.10, “Proxy Users”.
Several authentication plugins are available in MySQL:
Plugins that perform native authentication that matches the
password against the
Password column of the
account row. The
plugin implements authentication based on the native password
hashing method. The
plugin implements native authentication based on the older
(pre-4.1) password hashing method (and is deprecated and
removed in MySQL 5.7.5). See
Section 5.9.1, “The Native Authentication Plugin”, and
Section 5.9.2, “The Old Native Authentication Plugin”. Native
is the default for new accounts, unless the
variable is set otherwise.
A plugin that performs authentication using SHA-256 password
hashing. This plugin matches the password against the
authentication_string column of the account
row. This is stronger encryption than that available with
native authentication. See
Section 5.9.4, “The SHA-256 Authentication Plugin”.
A plugin prevents all client connections to any account that uses it. Use cases for such a plugin includes accounts that must be able to execute stored programs and views with elevated privileges without exposing those privileges to ordinary users, and proxy accounts that should never permit direct login. See Section 5.9.5, “The No-Login Authentication Plugin”.
A client-side plugin that sends the password to the server without hashing or encryption. This plugin can be used by server-side plugins that require access to the password exactly as provided by the client user. See Section 5.9.6, “The Cleartext Client-Side Authentication Plugin”.
A plugin that authenticates clients that connect from the local host through the Unix socket file. See Section 5.9.7, “The Socket Peer-Credential Authentication Plugin”.
A test plugin that authenticates using MySQL native authentication. This plugin is intended for testing and development purposes, and as an example of how to write an authentication plugin. See Section 5.9.8, “The Test Authentication Plugin”.
For information about current restrictions on the use of pluggable authentication, including which connectors support which plugins, see Restrictions on Pluggable Authentication.
Third-party connector developers should read that section to determine the extent to which a connector can take advantage of pluggable authentication capabilities and what steps to take to become more compliant.
If you are interested in writing your own authentication plugins, see Writing Authentication Plugins.
This section provides general instructions for installing and using authentication plugins.
In general, pluggable authentication uses corresponding plugins on the server and client sides, so you use a given authentication method like this:
On the server host, install the library containing the appropriate server plugin, if necessary, so that the server can use it to authenticate client connections. Similarly, on each client host, install the library containing the appropriate client plugin for use by client programs.
Create MySQL accounts that specify use of the plugin for authentication.
When a client connects, the server plugin tells the client program which client plugin to use for authentication.
The instructions here use an example authentication plugin included in MySQL distributions (see Section 5.9.8, “The Test Authentication Plugin”). The procedure is similar for other authentication plugins; substitute the appropriate plugin and file names.
The example authentication plugin has these characteristics:
The server-side plugin name is
The client-side plugin name is
Both plugins are located in the shared library object file
auth_test_plugin.so in the plugin
directory (the directory named by the
plugin_dir system variable).
The file name suffix might differ on your system.
Install and use the example authentication plugin as follows:
Make sure that the plugin library is installed on the server and client hosts.
Install the server-side test plugin at server startup or at runtime:
To install the plugin at startup, use the
--plugin-load option. With
this plugin-loading method, the option must be given each
time you start the server. For example, use these lines in
my.cnf option file:
To install the plugin at runtime, use the
INSTALL PLUGIN statement:
INSTALL PLUGIN test_plugin_server SONAME 'auth_test_plugin.so';
This installs the plugin permanently and need be done only once.
Verify that the plugin is installed. For example, use
SHOW PLUGINS\G... *************************** 21. row *************************** Name: test_plugin_server Status: ACTIVE Type: AUTHENTICATION Library: auth_test_plugin.so License: GPL
For other ways to check the plugin, see Obtaining Server Plugin Information.
To specify that a MySQL user must be authenticated using a
specific server plugin, name the plugin in the
IDENTIFIED WITH clause of the
CREATE USER statement that
creates the user:
CREATE USER 'testuser'@'localhost' IDENTIFIED WITH test_plugin_server;
Connect to the server using a client program. The test plugin
authenticates the same way as native MySQL authentication, so
provide the usual
--password options that you
normally use to connect to the server. For example:
For connections by
testuser, the server
sees that the account must be authenticated using the
server-side plugin named
and communicates to the client program which client-side
plugin it must use—in this case,
In the case that the account uses the authentication method
that is the default for both the server and the client
program, the server need not communicate to the client which
plugin to use, and a round trip in client/server negotiation
can be avoided. Currently this is true for accounts that use
native MySQL authentication
option can be specified on the mysql
command line to make explicit which client-side plugin the
program can expect to use, although the server will override
this if the user account requires a different plugin.
If the client program does not find the plugin, specify a
option to indicate where the plugin is located.
If you start the server with the
authentication plugins are not used even if loaded because the
server performs no client authentication and permits any client
to connect. Because this is insecure, you might want to use
--skip-networking to prevent
remote clients from connecting.