JWELoaderFactory and JWSLoaderFactory ignore the requested header checkers when they have no HeaderCheckerManagerFactory

Open
  • Is something wrong?
#768 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
56/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
php, symfony
Domain
authentication, backend

Research direction

Start with JWELoaderFactory and JWSLoaderFactory, then inspect the corresponding bundle factories and the service names described in the bundle documentation. Check how create() handles requested header checker aliases when no manager factory is available, including the empty list case. Done means the documented services are accurate and requested aliases cannot be silently ignored.

Written by the indexing model from the issue text.

Description

bug
Version(s) affected

All released versions since 1.1.0 (3.4.x, 4.0.x, 4.1.x, 4.2.x), and the 4.3.x and 5.0.x branches.

Description

The third constructor argument of Jose\Component\Encryption\JWELoaderFactory and Jose\Component\Signature\JWSLoaderFactory is a nullable HeaderCheckerManagerFactory. When it is null, create() ignores $headerCheckers and returns a loader without header checker manager, which checks no header parameter at all (typ, alg, crit, exp…). Nothing is thrown, even for an alias that does not exist, whereas an unknown serializer or algorithm alias is refused. NestedTokenLoaderFactory passes its two lists to these factories and behaves the same.

$factory = new JWELoaderFactory($serializerManagerFactory, $decrypterFactory, null);
$loader = $factory->create(['jwe_compact'], ['A256KW', 'A256GCM'], ['access_token_type']);
$loader->getHeaderCheckerManager(); // null

With the Symfony bundle this happens without anybody writing null. The bundle documentation fetches Jose\Component\Encryption\JWELoaderFactory (likewise JWSLoaderFactory, JWEDecrypterFactory, JWSVerifierFactory, the builder and checker manager factories) from the container, but since 2.0 the bundle registers Jose\Bundle\JoseFramework\Services\* instead. An application that then registers the library classes itself, with autowiring, gets null as third argument: no service has the type Jose\Component\Checker\HeaderCheckerManagerFactory, and the argument is nullable.

Loaders declared in the bundle configuration (jose.jwe.loaders, jose.jws.loaders) and loaders created by the bundle's own factories are not affected.

How to reproduce

With autowire: true, register Jose\Component\Encryption\JWEDecrypterFactory and Jose\Component\Encryption\JWELoaderFactory as services, and a TypeChecker('at+jwt') tagged jose.checker.header with the alias access_token_type. A loader created by the library factory with create(['jwe_compact'], ['A256KW', 'A256GCM'], ['access_token_type']) accepts a JWE whose protected header has "typ":"refresh+jwt". The loader created by the bundle's factory with the same arguments rejects it with Unsupported type..

Possible Solution
  • Throw an InvalidArgumentException from create() when header checker aliases are requested and no HeaderCheckerManagerFactory is available, and keep returning a loader without manager for an empty list. Same change in the two factories of the bundle.
  • Fix the bundle documentation so that it names the services the bundle registers.
  • 5.0.0: consider making the argument non-nullable, which turns the autowiring case into a container error.
  • Changelog: such a configuration now fails when the loader is created.
Additional Context

Found by the Anthropic OSS Scanner (ANT-2026-F6XYPNCA).

Dominant language
PHP
Stars
954
Forks
119
Avg merge
48m
Merged PRs (30d)
17

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from web-token/jwt-framework

All issues in web-token/jwt-framework

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.