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
system table. The server then authenticates the client,
determining from the account row which authentication plugin
applies to the client:
If the server cannot find the plugin, an error occurs and the connection attempt is rejected.
Otherwise, the server invokes that plugin to authenticate the user, and the plugin returns a status to the server indicating whether the user provided the correct password and is permitted to connect.
Pluggable authentication enables these important capabilities:
Choice of authentication methods. Pluggable authentication makes it easy for DBAs to choose and change the authentication method used for individual MySQL accounts.
External authentication. Pluggable authentication makes it possible for clients to connect to the MySQL server with credentials appropriate for authentication methods that store credentials elsewhere than in the
mysql.usersystem 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 (the proxied user). While the connection lasts, the proxy user is treated, for purposes of access control, as having the privileges of the proxied user. In effect, one user impersonates another. For more information, see Section 6.3.10, “Proxy Users”.
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.
MySQL 5.7 provides these authentication plugins:
Plugins that perform native authentication; that is, authentication based on the password hashing methods in use from before the introduction of pluggable authentication in MySQL. The
mysql_native_passwordplugin implements authentication based on the native password hashing method. The
mysql_old_passwordplugin 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 22.214.171.124, “Native Pluggable Authentication”, and Section 126.96.36.199, “Old Native Pluggable Authentication”.
Plugins that perform authentication using SHA-256 password hashing. This is stronger encryption than that available with native authentication. See Section 188.8.131.52, “SHA-256 Pluggable Authentication”, and Section 184.108.40.206, “Caching SHA-2 Pluggable Authentication”.
A client-side plugin that sends the password to the server without hashing or encryption. This plugin is used in conjunction with server-side plugins that require access to the password exactly as provided by the client user. See Section 220.127.116.11, “Client-Side Cleartext Pluggable Authentication”.
A plugin that performs external authentication using PAM (Pluggable Authentication Modules), enabling MySQL Server to use PAM to authenticate MySQL users. This plugin supports proxy users as well. See Section 18.104.22.168, “PAM Pluggable Authentication”.
A plugin that performs external authentication on Windows, enabling MySQL Server to use native Windows services to authenticate client connections. Users who have logged in to Windows can connect from MySQL client programs to the server based on the information in their environment without specifying an additional password. This plugin supports proxy users as well. See Section 22.214.171.124, “Windows Pluggable Authentication”.
Plugins that perform authentication using LDAP (Lightweight Directory Access Protocol) to authenticate MySQL users by accessing directory services such as X.500. These plugins support proxy users as well. See Section 126.96.36.199, “LDAP Pluggable Authentication”.
A plugin that prevents all client connections to any account that uses it. Use cases for this plugin include proxied accounts that should never permit direct login but are accessed only through proxy accounts and accounts that must be able to execute stored programs and views with elevated privileges without exposing those privileges to ordinary users. See Section 188.8.131.52, “No-Login Pluggable Authentication”.
A plugin that authenticates clients that connect from the local host through the Unix socket file. See Section 184.108.40.206, “Socket Peer-Credential Pluggable Authentication”.
A test plugin that checks account credentials and logs success or failure to the server error log. This plugin is intended for testing and development purposes, and as an example of how to write an authentication plugin. See Section 220.127.116.11, “Test Pluggable Authentication”.
For information about current restrictions on the use of pluggable authentication, including which connectors support which plugins, see Section C.9, “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 Section 18.104.22.168, “Writing Authentication Plugins”.
This section provides general instructions for installing and using authentication plugins. For instructions specific to a given plugin, see the section that describes that plugin under Section 6.5.1, “Authentication Plugins”.
In general, pluggable authentication uses a pair of corresponding plugins on the server and client sides, so you use a given authentication method like this:
If necessary, install the plugin library or libraries containing the appropriate plugins. On the server host, install the library containing the server-side plugin, so that the server can use it to authenticate client connections. Similarly, on each client host, install the library containing the client-side plugin for use by client programs. Authentication plugins that are built in need not be installed.
For each MySQL account that you create, specify the appropriate server-side plugin to use for authentication. If the account is to use the default authentication plugin, the account-creation statement need not specify the plugin explicitly. The
default_authentication_pluginsystem variable configures the default authentication plugin.
When a client connects, the server-side plugin tells the client program which client-side plugin to use for authentication.
In the case that an account uses an authentication method that is the default for both the server and the client program, the server need not communicate to the client which client-side plugin to use, and a round trip in client/server negotiation can be avoided. This is true for accounts that use native MySQL authentication.
For standard MySQL clients such as mysql and
option can be specified on the command line as a hint about
which client-side plugin the program can expect to use, although
the server will override this if the server-side plugin
associated with the user account requires a different
If the client program does not find the client-side plugin
library file, specify a
option to indicate the plugin library directory location.