Pluggable Authentication Authentication Plugin Client/Server Compatibility Authentication Plugin Connector-Writing Considerations Pluggable authentication enables flexibility in the choice of authentication methods for MySQL accounts, but in some cases client connections cannot be established due to authentication plugin incompatibility between the client and server. The general compatibility principle for a successful client connection to a given account on a given server is that the client and server both must support the authentication  method  required by the account. Because authentication methods are implemented by authentication plugins, the client and server both must support the authentication  plugin  required by the account. Authentication plugin incompatibilities can arise in various ways. Examples: In general, these compatibility issues do not arise when connections are made between a client and server from the same MySQL distribution. When connections are made between a client and server from different MySQL series, issues can arise. These issues are inherent in the development process when MySQL introduces new authentication plugins or removes old ones. To minimize the potential for incompatibilities, regularly upgrade the server, clients, and connectors on a timely basis. Various implementations of the MySQL client/server protocol exist. The  libmysqlclient C API client library is one implementation. Some MySQL connectors (typically those not written in C) provide their own implementation. However, not all protocol implementations handle plugin authentication the same way. This section describes an authentication issue that protocol implementors should take into account. In the client/server protocol, the server tells connecting clients which authentication plugin it considers the default. If the protocol implementation used by the client tries to load the default plugin and that plugin does not exist on the client side, the load operation fails. This is an unnecessary failure if the default plugin is not the plugin actually required by the account to which the client is trying to connect. If a client/server protocol implementation does not have its own notion of default authentication plugin and always tries to load the default plugin specified by the server, it fails with an error if that plugin is not available. To avoid this problem, the protocol implementation used by the client should have its own default plugin and should use it as its first choice (or, alternatively, fall back to this default in case of failure to load the default plugin specified by the server). Example: 1261 •In MySQL 5.7,  libmysqlclient  uses as its default choice either  mysql_native_password  or the plugin specified through the  MYSQL_DEFAULT_AUTH  option for  mysql_options() . •Connect using a MySQL 5.7 client from a Community distribution to a MySQL 5.7 Enterprise server account that authenticates using one of the Enterprise-only LDAP authentication plugins. This fails because the Community client does not have access to the Enterprise plugin. •Connect using a MySQL 5.7 client to a pre-5.7 server account that authenticates with mysql_old_password . This fails for multiple reasons. First, such a connection requires  --secure- auth=0 , which is no longer a supported option. Even were it supported, the 5.7 client does not recognize the plugin because it was removed in MySQL 5.7. •Connect using a MySQL 5.7 client from 5.7.22 or lower to a MySQL 8.0 server account that authenticates with  caching_sha2_password . This fails because the 5.7 client does not recognize the plugin, which was introduced in MySQL 8.0. (This issue is addressed in MySQL 5.7 as of 5.7.23, when  caching_sha2_password  client-side support was added to the MySQL client library and client programs.)