Support jwt gem 3.x alongside 2.x

[dan98765]

Changes

Widens the jwt runtime dependency from ~> 2.7 (which caps at < 3.0) to >= 2.7, < 4.0. This lets consumers that depend on both auth0 and a gem requiring jwt 3.x (e.g. workos >= 6.0) resolve without conflicts.

No code changes — just the gemspec constraint and the lockfile.

References

• Support jwt gem version 3 #690 — community request for jwt 3.x support
• jwt 3.0 changelog
• The workos gem pinned jwt ~> 3.1 starting at v6.0, making it impossible to use workos >= 6 with auth0 today

Testing

Ran the full test suite (bundle exec rake test) on Ruby 3.3.9 with jwt 3.1.2 resolved:

• 1040 unit examples, 0 failures
• 164 integration examples, 0 failures (1 pending — pre-existing)
• Line coverage: 99.56%

No new tests needed since this is a dependency constraint change and all existing JWT-related tests already pass against 3.x.

• This change adds unit test coverage
• This change adds integration test coverage
• This change has been tested on the latest version of Ruby

Checklist

• I have read the Auth0 general contribution guidelines
• I have read the Auth0 Code of Conduct
• All existing and new tests complete without errors
• Rubocop passes on all added/modified files (note: rubocop fails to start due to a pre-existing config issue in .rubocop_todo.yml — Metrics/LineLength renamed to Layout/LineLength — unrelated to this change)
• All active GitHub checks have passed

[arpit-jn]

LGTM. The change is minimal, well-scoped, and the test results are convincing (1040 unit + 164 integration, zero failures on jwt 3.1.2).

Ask: Could you rebase onto master to resolve the Gemfile.lock conflict? We just shipped v5.19.0 which updated the lockfile. Should be a quick bundle install after rebase.

[dan98765]

Ask: Could you rebase onto master to resolve the Gemfile.lock conflict? We just shipped v5.19.0 which updated the lockfile. Should be a quick bundle install after rebase.

No prob, updated.

[dan98765]

Rebased and conflict resolved — anything else needed to get this merged?

[joshgaber]

@arpit-jn @dan98765 Now that the Ruby-JWT maintainers have published CVE-2026-44351, I'm sure a lot of users are scrambling to upgrade this gem as soon as possible. Is there anything we can do to help expedite this?

Second question: Should the jwt version be pegged to 3.2 or higher? I'd imagine you'd want to prevent developers from using insecure gems with your product where possible.

[krijnr]

We need this now: CVE-2026-44351
We are out of compliance for vulnerability management due to this issue.
Auth0 is who we trust for our auth... (should we?)

[arpit-jn]

Apologies for the delay here. Merging this now and will cut a release tomorrow so the updated constraint is available on RubyGems.

Re the CVE concern from @joshgaber, the widened constraint (>= 2.7, < 4.0) allows both patched versions (2.10.3 for 2.x, 3.2.0 for 3.x). We can't exclude only vulnerable ranges in a single gemspec constraint without forcing everyone onto 3.x, so the pragmatic approach is to unblock the upgrade path and let users resolve to the patched version via bundle update jwt.

@krijnr Once the release is published, updating your Gemfile.lock should get you to the patched jwt version.

Thanks @dan98765 for the contribution.