phacility/phabricator · error · Exception

The authentication provider did not return the correct clien

Error message

The authentication provider did not return the correct client state parameter in its response. If this problem persists, you may need to clear your cookies.

What it means

Thrown by PhabricatorAuthProvider::verifyAuthCSRFCode() when the provider did return a state parameter but it does not match the expected digest of the client's phcid cookie (comparison via phutil_hashes_are_identical, i.e. constant-time). This means the handshake was bound to a different browser/client state than the one completing it — the classic CSRF/forged-callback signal, though in practice it is usually caused by cookies changing mid-flow.

Source

Thrown at src/applications/auth/provider/PhabricatorAuthProvider.php:574

        true);
    }

    return PhabricatorHash::weakDigest($phcid);
  }

  protected function verifyAuthCSRFCode(AphrontRequest $request, $actual) {
    $expect = $this->getAuthCSRFCode($request);

    if (!strlen($actual)) {
      throw new Exception(
        pht(
          'The authentication provider did not return a client state '.
          'parameter in its response, but one was expected. If this '.
          'problem persists, you may need to clear your cookies.'));
    }

    if (!phutil_hashes_are_identical($actual, $expect)) {
      throw new Exception(
        pht(
          'The authentication provider did not return the correct client '.
          'state parameter in its response. If this problem persists, you may '.
          'need to clear your cookies.'));
    }
  }

  public function supportsAutoLogin() {
    return false;
  }

  public function getAutoLoginURI(AphrontRequest $request) {
    throw new PhutilMethodNotImplementedException();
  }

  protected function getContentSecurityPolicyFormActions() {
    return array();
  }

View on GitHub (pinned to 5720a38cfe)

Solutions

Retry the login in a single browser from start to finish — begin at the Phabricator login page and let the redirect complete in the same session.
Clear Phabricator cookies for the site first so a fresh phcid cookie is issued and stays stable through the flow.
If it persists, check that the auth flow is not spanning domains (e.g. alternate hostnames for the IdP callback vs Phabricator) and that nothing rewrites the state parameter.
Administrators should confirm the provider config's callback URI exactly matches the IdP-registered redirect so the round-trip stays unmodified.

Defensive patterns

Strategy: try-catch

Try / catch

try {
  $provider->verifyAuthCSRFCode($request, $state);
} catch (Exception $ex) {
  // state mismatch: reject the callback as untrusted, restart the flow from
  // the login page (fresh cookie), and log the mismatched pair for auditing
}

Prevention

Complete the entire login flow in one browser; avoid cross-device callback handoffs.
Keep the callback URI registered with the IdP byte-identical to the configured one.
Do not bookmark or share callback URLs — they are single-use and cookie-bound.

When it happens

Trigger: The user starts login in browser A but the IdP callback lands in browser B or a browser whose phcid cookie was re-issued; cookies were cleared or expired between the authorization redirect and the callback; the callback URL is opened from a different device, a restored bookmark, or a link shared from someone else's login; a forged callback attempt.

Common situations: Cross-device or cross-browser handoff (login started on desktop, approved on phone with synced tabs); SSO popup blockers forcing a manual copy of the callback URL; cookie churn from domain changes; aggressive cookie auto-clearing extensions.

Understand the failure class

Authentication and authorization failures — expired tokens, bad credentials, and missing scopes.

Related errors

AI-assisted analysis of phacility/phabricator@5720a38cfe (2026-08-21). Data as JSON: /api/errors/769be87be0035119. Report an issue: GitHub.