Problem/Motivation

JWT (OAuth 2.0 JWT Bearer) authentication regresses in 5.1.3-beta2. After updating drupal/salesforce from a recent 5.1.x-dev build to 5.1.3-beta2, JWT auth providers can no longer obtain an access token: Salesforce returns 400 Bad Request {"error":"invalid_client_id"} from the token endpoint — even though the Connected App, Consumer Key, X.509 certificate, and run-as user are unchanged and verified correct. The identical configuration authenticates successfully on the prior version.

5.1.3-beta2 adds commit a97075fa ("OAuth refactor"), a large rewrite of the auth/token subsystem — including a ~408-line rewrite of modules/salesforce_jwt/src/Plugin/SalesforceAuthProvider/SalesforceJWTPlugin.php. The regression originates with that refactor: the last 5.1.x-dev commit preceding it authenticates fine; 5.1.3-beta2 does not.

Steps to reproduce

  1. A site using salesforce_jwt with a working JWT auth provider
    (Consumer Key, run-as user, certificate uploaded to the Connected App's
    "Use digital signatures").
  2. Confirm JWT auth works on 5.1.x-dev at the commit immediately
    before a97075fa.
  3. composer require drupal/salesforce:5.1.3-beta2, then
    drush cr.
  4. Trigger any Salesforce API call (or the auth provider's connection check).
  5. Observed: the token request fails —
    POST https://<instance>/services/oauth2/token
    400 {"error":"invalid_client_id"}; Drupal logs an
    OAuth\Common\Storage\Exception\TokenNotFoundException from
    SalesforceAuthTokenStorage::retrieveAccessToken().
  6. Reverting drupal/salesforce to the pre-a97075fa
    commit restores JWT authentication with the identical configuration.

Environment: Drupal core 10.6.x, PHP 8.3, salesforce 5.1.3-beta2,
salesforce_jwt enabled. Every environment running 5.1.3-beta2 is
affected; environments still on the prior version are not.

Proposed resolution

Identify and fix the defect introduced by the a97075fa OAuth
refactor that causes the JWT bearer token request to be rejected with
invalid_client_id — most likely in how the rewritten
SalesforceJWTPlugin builds the token request or passes the
client_id (Consumer Key). Restore the pre-regression JWT behaviour.

Remaining tasks

  • Bisect the three commits in 5.1.3-beta2 to confirm a97075fa
    is the cause and isolate the specific change.
  • Patch SalesforceJWTPlugin (and related auth/token classes if
    needed).
  • Add automated test coverage for JWT token acquisition.
  • Tag a fixed release (5.1.3-beta3).

User interface changes

None.

API changes

None proposed — this is a regression fix; it should restore the pre-refactor JWT behaviour without a further API change.

Data model changes

None.

Issue fork salesforce-3591406

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

anicoto created an issue. See original summary.

anicoto’s picture

Confirming the exact version delta for whoever picks this up.

Last known-good build: 5.1.x-dev at commit
b4899a7886db3a6eaaa99918545de4854e0c3fad (5.1.2 + 26
dev commits). 5.1.3-beta2 is that commit plus exactly three:

  • a97075facebf8dfde869bc01f192823c41777390 — "OAuth refactor"
    (2026-05-08) — rewrites
    modules/salesforce_jwt/src/Plugin/SalesforceAuthProvider/SalesforceJWTPlugin.php
    (~408 lines) plus the wider auth/token subsystem.
  • c79dbf736f51e4a3909cd39d4f45a979736bcbfd — "Restore deprecated
    requirement constants, for < 11.2 support" — only touches
    salesforce.install.
  • b7e6be233a3cba45ed91c2c8d2538667916fc2e8 — "Clean up token
    inheritance" — a 2-line change to SalesforceAuthTokenStorage.

JWT authentication works at b4899a7 and fails at
5.1.3-beta2 with invalid_client_id.
a97075fa is the clear suspect — it is the only one of the three
that rewrites the JWT plugin — but I have not git-bisected the three commits to
confirm.

Workaround for anyone else hitting this — pin to the commit before the
refactor:

composer require
  "drupal/salesforce:dev-5.1.x#b4899a7886db3a6eaaa99918545de4854e0c3fad"

Happy to test a patch against our setup (JWT bearer flow, Drupal core 10.6,
PHP 8.3).

aaronbauman made their first commit to this issue’s fork.

aaronbauman’s picture

Version: 5.1.3-beta2 » 5.1.x-dev
Status: Active » Needs review

Thank you for the detailed bug report and investigation, very helpful.
Please try MR130 and see if the issue is resolved.

aaronbauman’s picture

Status: Needs review » Fixed

Merged a similar but separate resolution from MR130, which I'm pretty confident will address this.

Please reopen if latest dev doesn't work for you.

I'll be cutting a new beta tag shortly.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.