“The state parameter is not verified” error

This OAuth error indicates that the state parameter (i.e., the “opaque value used by the client to maintain state between the request and callback”; see section 4.1.1 of the OAuth 2.0 specification) cannot be verified. There are two possible causes:

  1. A maintenance plugin is turned on
  2. Inadvertent caching of the login script (wp-login.php or its renamed equivalent)
  3. Errors or warnings in other plugins

A maintenance plugin is turned on

The simplest reason this could be happening is that you have a maintenance plugin turned on that is affecting the way pages are loaded. If you do have one turned on, try disabling it and logging in. If that doesn't work, it is likely the other causes. Some plugins known to cause this issue are:

Inadvertent caching of the login script

To fix the issue

  • Purge the appropriate server and application cache(s)
  • Disable or exclude caching for the WP login script in these caches
  • And refresh the login script in your browser.

Depending on your web hosting setup, there are several potential caching layers at which you may need to perform the fix. If you are using traditional shared web hosting or a managed WP hosting service, then be sure to check options A, B and C below. If you are self-hosting WP on your own VPS, also check option D.

(A) WP caching plugins

If your site is running  a caching plugin such as W3 Total Cache, WordFence, QuickCache, et al., then make sure that the plugin excludes the login script from the cache. 

Many caching plugins exclude wp-login.php by default. If you have renamed the login script, then it is likely you need to add a custom rule to your caching plugin to exclude the renamed login script location from the cache. Make sure that this bypass rule includes URL parameters. Ordinarily, this is achieved by using the wildcard character (i.e., *) in the rule (e.g., wp-login.php* or /my-secret-login-script-name/*).

(B) File and object caches on managed WP hosts

If your site is hosted by a managed WP hosting provider that employs its own caching system (e.g., WPEngine, GoDaddy managed WP, et al.), it is likely that the default login script location (/wp-login.php) is already excluded from the cache. However, if you have renamed the login script location, you may need to purge your (a) files cache and (b) object cache (assuming you have turned on the object caching feature) within your hosting control panel. Also, you may need to contact your hosting provider to verify that your site's renamed login script is being excluded from the host's cache.

(C) Reverse proxy caches

If your WP site is behind a reverse proxy such as CloudFlare, Sucuri, et al., make sure that your proxy caching rules exclude the login script or its renamed equivalent from the proxy cache.

Note: Avoid using /wp-* as a pattern, which would inadvertently exclude all files in /wp-content/. Rather, either use individual rules for /wp-admin/ and /wp-login.php, or use the /*wp-*in* pattern, which excludes both /wp-admin/ and /wp-login.php without also excluding /wp-content/

(D) Server-side PHP caches

If your production or development environment web server stack employs any of the following caching systems, then you may need to (a) purge the appropriate cache and (b) set a cache bypass rule for your site's login script.

  • APC
  • eAccellerator
  • Nginx fastcgi cache
  • OPcache
  • Varnish
  • XCache

Note: adjusting server-side caches may require restarting Apache/Nginx for the change to take effect.

Errors or warnings in other plugins

To fix this issue,

  1. Enable WP_DEBUG on your site
  2. Find and fix any warnings or errors that appear when visiting the login page