web-token / jwt-framework

JWT Framework

PHP JWT Framework

Documentation

The official documentation is available as https://web-token.spomky-labs.com/

Support

I bring solutions to your problems and answer your questions.

If you really love that project, and the work I have done or if you want I prioritize your issues, then you can help me out for a couple of 🍻 or more!

Become a sponsor

Or

Contributing

Requests for new features, bug fixed and all other ideas to make this library useful are welcome. Please follow these best practices.

If you discover a security vulnerability within the project, please don't use the bug tracker and don't publish it publicly. Instead, all security issues must be sent to security [at] spomky-labs.com.

Licence

This software is release under MIT licence.

jwt-framework's Issues

why jws not allow RSA & ES256?

Q	A
Bug report?	yes
Feature request?	no
BC Break report?	no
RFC? / Specification	no
Version	latest

jws will Exception as follows when deal with RSA & ES256.

ECDSA only allow "EC" type.
now what to do ?

Type: InvalidArgumentException Message: Wrong key type. File: ./jwt_framework/jwt-signature/vendor/web-token/jwt-signature/Algorithm/ECDSA.php Line: 92

[Symfony] How to prevent jku request when testing?

For my tests I have created a test jwk set and I put this in a test override config file:

packages/test/jose.yaml:

jose:
    key_sets:
        openid_key_test:
            jwkset: 
                value: 'my test jwk set'

Now I also override my authentication service configuration with the test keyset instead of the normal JKU keyset.

services_test.yaml

    test.App\Service\MyAuthService:
        class: App\Service\MyAuthService
        arguments:
            - '@jose.key_set.openid_key_test'

The problem is that, even though the JKU keyset is never used when testing it still tries to request it. Now I would rather prevent this as this makes my tests dependent on this external endpoint which I don't want to use.

Why does this happen? Does Symfony resolve all the keysets (which triggers the HttPlug request) even though they aren't used? How can I prevent this?

I tried overriding the normal keyset with a new config, but then jwt-framework will error on the keyset having both a jku url and a jwk keyset.

Proposal: Allow definition of required claims and headers

Q	A
Bug report?	no
Feature request?	yes
BC Break report?	no
RFC? / Specification	no

Currently, the HeaderCheckerManager will perform validation on a header value only if that header is present in the token. I believe it would improve security to enforce a rule that tokens my application consumes must have a certain set of header and payload claims present. For example, I would like to specify that any token I consume always has a kid header claim present. This is in addition to validating the kid header's value.

One option I considered was to throw an exception if array_key_exists is falsey here, but I suspect that would complicate things for folks who are using valid tokens whose claims might vary from use to use.

An alternative would be to add a new kind of header and payload validation manager, wherein a user could specify a list of protected, unprotected, and/or payload claims they expect to be present on any token, something to the effect of:

$requiredProtectedHeaders = [
    'kid',
];

$requiredUnprotectedHeaders = [];

$requiredProtectedClaims = [
    'sub',
    'required-custom-claim-one',
    'required-custom-claim-two',
];

$requiredClaimPresenceChecker = RequiredClaimPresenceCheckerManager::create(
    $requiredProtectedHeaders,
    $requiredUnprotectedHeaders,
    $requiredProtectedClaims
);

$requiredClaimPresenceChecker->check($token); // $token being, for example, a JWS instance

What do you think about this idea? If you agree that this might be useful, would you prefer that a required claim checker for the payload be a separate object from the required header claim checker?

If you think this is a reasonable idea, I would be happy to open a pull request to begin work on this. In the mean time, I can resort to validating "required" claims more manually using your toolset in my application.

Thanks!

Dedicated package for ECC Utils

Q	A
Bug report?	no
Feature request?	no
BC Break report?	no
RFC? / Specification	no
Version	v1.x

Classes in the namespace Jose\Component\Encryption\Util\Ecc are only needed for some use cases (e.g. ECDH-ES encryption or key mgmt).
These classes should be part of a dedicated package.

[Insight] Code should not be duplicated - in src/Bundle/…/Source/JWEBuilder.php, line 53

in src/Bundle/Encryption/DependencyInjection/Source/JWEBuilder.php, line 53

The next 51 lines appear both in src/Bundle/Encryption/DependencyInjection/Source/JWEBuilder.php:53 and src/Bundle/Encryption/DependencyInjection/Source/JWEDecrypter.php:53.

                    $itemConfig['key_encryption_algorithms'],
                    $itemConfig['content_encryption_algorithms'],
                    $itemConfig['compression_methods'],
                ])
                ->addTag('jose.jwe_builder')
                ->setPublic($itemConfig['is_public']);

            $container->setDefinition($service_id, $definition);
        }
    }

---

Posted from SensioLabsInsight

JWS/JWE Split

Q	A
Bug report?	no
Feature request?	yes
BC Break report?	no
RFC? / Specification	no
Version	v1.1.0

Allow JWS/JWE with multiple signatures/recipients to be split into an array of JWS/JWE with only one signature/recipient.

Example (JSON notation):

{
    "payload": "eyJpc3Mi...VlfQ",
    "signatures":[
        {
            "protected":"eyJhbGciOiJSUzI1NiJ9",
            "header": {"kid":"2010-12-29"},
            "signature": "cC4hiUPoj9Eetdgtv3h...IoypGlUPQGe77Rw"
        },{
            "protected":"eyJhbGciOiJFUzI1NiJ9",
            "header":  {"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"},
            "signature": "DtEhU3l...jbEg8U1Q"
        }]
}

{
    "payload": "eyJpc3Mi...VlfQ",
    "protected":"eyJhbGciOiJSUzI1NiJ9",
    "header": {"kid":"2010-12-29"},
    "signature": "cC4hiUPoj9Eetdgtv3h...IoypGlUPQGe77Rw"
}

and 

{
    "payload": "eyJpc3Mi...VlfQ",
    "protected":"eyJhbGciOiJFUzI1NiJ9",
    "header":  {"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"},
    "signature": "DtEhU3l...jbEg8U1Q"
}

Console Commands for JWE/JWS Creation

Q	A
Bug report?	no
Feature request?	yes
BC Break report?	no
RFC? / Specification	no
Version	2.0

Add commands to allow the creation of tokens from the CLI.

• Create JWS
  • Set payload
  • For each signature
    • Set signature key
    • Set protected header
    • Set unprotected header
  • Choose serialization mode
• Create JWE
  • Set payload
  • Set protected shared header (optional)
  • Set unprotected shared header (optional)
  • Set AAD (optional)
  • For each recipient
    • Set recipient key
    • Set recipient header
  • Choose serialization mode

Change headers into header

Q	A
Bug report?	no
Feature request?	no
BC Break report?	yes
RFC? / Specification	no
Version	1.x

Decryption error - too few arguments passed to decryptUsingKey

Receiving Fatal error: Uncaught ArgumentCountError: Too few arguments to function Jose\Component\Encryption\JWEDecrypter::decryptUsingKey(), 2 passed in ... expecting 3.

I am using the example listed on this page.
https://web-token.spomky-labs.com/component/jwe/loading.html
Error occurs here:
$jwe = $jweDecrypter->decryptUsingKey($jwe, $jwk);

The source code looks like it expects a $recipient integer parameter, but I have no idea what to put for this.

Thanks!

Create tokens using secret (string)

Q	A
Bug report?	no
Feature request?	no
BC Break report?	no
RFC? / Specification	no
Version	x.y(.z)

I'm trying to use this library to generate JWTs. In other languages/frameworks, I'm accustomed to passing in a secret (string). In this library, it appears I must construct a JWK. Since this tokens will be consumed in other projects, using other languages and frameworks, I'm trying to ensure I set things up correctly.

If I have a secret (say abc123) that I'm using in another project, how would I use that in this library? I noticed the documentation refers to JWKFactory::createFromSecret. But this seems to have been removed. Is there another way to accomplish what I'm trying to do?

[FIO] Cleartext JWE

Q	A
Bug report?	no
Feature request?	no
BC Break report?	no
RFC? / Specification	https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jwe-00
Version	?

Specification Design Issues

Q	A
Bug report?	no
Feature request?	no
BC Break?	no
RFC? / Specification	no
Version	all

The framework covers all the specifications and also includes experimental features from drafts.
It appears that the design of these specifications leads to misuse and potential security issues.

Non-exhaustive list of misuse:

• Using JWT for session management
• Mixing symmetric/asymmetric algorithms (see #150)
• Mixing public/private keys in a key set (see #150)
• Using weak algorithms (RSA1_5 and all non-authenticated encryption algorithms in general)
• Using vulnerable keys (low exponent, invalid curves, short keys...)
• Using/Manipulating claims that have not been correctly checked or are not really understood
• Lack of logging/monitoring (#152)
  • List of loaded/issued tokens
  • For each loaded token
    • List all checked claims and headers
    • Show keys used to verify the signature or decrypt the payload
• Sensitive data exposure

This framework provides a very limited set of classes or collectors to help the developpers.
It clearly appears that it is not enough.

Additional tools should be added. These tools should be able to warn the developpers in dev and in production mode by providing e.g. reports or log messages. These tools might be grouped in a dedicated package.
Security Recommendations available in the documentation have to be updated.

The algorithms provided by this framework are split into packages by family (RSA, EC...) + experimental.
A new package might be create for all insecured algorithms (e.g. RSA1_5) that are no longer recommended.

i want jwk to pem

Q	A
Bug report?	no
Feature request?	yes
BC Break report?	no
RFC? / Specification	yes
Version	x.y(.z)

i want jwk to pem

Middleware component

Q	A
Bug report?	no
Feature request?	yes
BC Break report?	no
RFC? / Specification	no
Version	1.x

Most of time, JWT are used in a web context and send through the Authorization header (other means may also be considered).
A new Middleware component, compliant with the applicable PSR, could be added. This will allow developers to easily catch tokens, verify/decrypt them and attach them the the request.

phpbench missing

Q	A
Bug report?	yes
Feature request?	no
BC Break report?	no
RFC? / Specification	no
Version	1.2.3

It does not appear that the phpbench library is actually installed, so it's not possible to run the benchmarks. Adding it to the require-dev gets it working fine.

Algorithms shoud have their own package

Q	A
Bug report?	no
Feature request?	yes
BC Break report?	to be confirmed
RFC? / Specification	no
Version	v1.x

At the moment, the packages web-token/jwt-signature and web-token/jwt-encryption come with a bunch of algorithms.
This causes some problems and unnecessary requirements (OpenSSL, libSodium...) for applications that use a limited list of algorithms (e.g. HSxxx).

This can be linked to the #97 that introduces new algorithms.

The idea is to remove the algorithms from the two packages listed above and create dedicated packages.
These dedicated packages will be required for v1.x of the project to avoid BC breaks, but will be decoupled for next major revisions and only suggested.

Following packages will be created:

• For signature:
  • web-token/jwt-signature-algorithm-none: none algorithm
  • web-token/jwt-signature-algorithm-rsa: all RSxxx and PSxxx algorithms
  • web-token/jwt-signature-algorithm-ecdsa: all ESxxx algorithms
  • web-token/jwt-signature-algorithm-eddsa: EdDSA algorithm
  • web-token/jwt-signature-algorithm-hmac: all HSxxx algorithms
• For encryption:
  • web-token/jwt-encryption-algorithm-aeskw: all AxxxKW algorithms
  • web-token/jwt-encryption-algorithm-aesgcmkw: all AxxxGCMKW algorithms
  • web-token/jwt-encryption-algorithm-dir: dir algorithm
  • web-token/jwt-encryption-algorithm-ecdh-es: all ECDH-ES algorithms
  • web-token/jwt-encryption-algorithm-pbes2: all PBES2-HSxxx+AyyyKW algorithms
  • web-token/jwt-encryption-algorithm-rsa: all RSA* algorithms
  • web-token/jwt-encryption-algorithm-aescbc: all AxxxCBC+HSyyy algorithms
  • web-token/jwt-encryption-algorithm-aesgcm: all AxxxGCM algorithms

error:0607A082:digital envelope routines:EVP_CIPHER_CTX_set_key_length:invalid key length

Q	A
Bug report?	Yes
Feature request?	no
BC Break report?	no
RFC? / Specification	no
Version	x.y(.z)

For the life of me I can't figure out what's going on. I can't decode my payload

Here's my code
https://pastebin.com/fKdVg3qP

Here's the payload
https://pastebin.com/jsjCrRrQ

Am I missing something? Is maybe my SSL version corrupted?

Thanks

JWKSet Cache Control Header ignored

Q	A
Bug report?	yes
Feature request?	no
BC Break report?	yes
RFC? / Specification	no
Version	1.2

Please refer to discussions in the following issues/PR:

• symfony/symfony#25736
• symfony/symfony#25583
• symfony/symfony#25699

The cache feature could be completely deprecated. Application will have to define their own cache strategy.

JWE / JWK question

Inside the documentation of JWE there is this small section:

// Our key.
$jwk = JWK::create([
    'kty' => 'oct',
    'k' => 'dzI6nbW4OcNF-AtfxGAmuyz7IpHRudBI0WgGjZWgaRJt6prBn3DARXgUR8NVwKhfL43QBIU2Un3AvCGCHRgY4TbEqhOi8-i98xxmCggNjde4oaW6wkJ2NgM3Ss9SOX9zS3lcVzdCMdum-RwVJ301kbin4UtGztuzJBeg5oVN00MGxjC2xWwyI0tgXVs-zJs5WlafCuGfX1HrVkIf5bvpE0MQCSjdJpSeVao6-RSTYDajZf7T88a2eVjeW31mMAg-jzAWfUrii61T_bYPJFOXW8kkRWoa1InLRdG6bKB9wQs9-VdXZP60Q4Yuj_WZ-lO7qV9AEFrUkkjpaDgZT86w2g',
]);

But it's unclear for me how the k has been generated?

+Algorithms

Q	A
Bug report?	no
Feature request?	yes
BC Break report?	no
RFC? / Specification	draft-irtf-cfrg-webcrypto-algorithms, RFC8152, RFC8230
Version	v1.2.0?

Many algorithms have been referenced in the COSE specification (see #96) and other specification.
See #96, https://www.iana.org/assignments/cose/cose.xhtml#algorithms and https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms

Some of these algorithms can be added. For those that are prohibited, an implementation can be done with explicit warnings.

Hereafter some potential algorithms (prohibited ones in bold):

Target for v1.2:

• RS1 (should be easy to implement)
• HS1 (should be easy to implement)
• HMAC 256/64 (should be easy to implement)
• RSAES-OAEP w/ SHA-384 (should be easy to implement)
• RSAES-OAEP w/ SHA-512 (should be easy to implement)
• ChaCha20/Poly1305 (should be easy to implement)
• AES-CCM-16-64-128 (should be easy to implement)
• AES-CCM-16-64-256 (should be easy to implement)
• AES-CCM-64-64-128 (should be easy to implement)
• AES-CCM-64-64-256 (should be easy to implement)
• AES-CCM-16-128-128 (should be easy to implement)
• AES-CCM-16-128-256 (should be easy to implement)
• AES-CCM-64-128-128 (should be easy to implement)
• AES-CCM-64-128-256 (should be easy to implement)
• A128CTR (should be easy to implement)
• A192CTR (should be easy to implement)
• A256CTR (should be easy to implement)

Target for v2.0+:

• A128CBC (should be easy to implement)
• A192CBC (should be easy to implement)
• A256CBC (should be easy to implement)
• ECDH-SS + A256KW (to be discussed)
• ECDH-SS + A192KW (to be discussed)
• ECDH-SS + A128KW (to be discussed)
• ECDH-SS + HKDF-512 (to be discussed)
• ECDH-SS + HKDF-256 (to be discussed)
• ECDH-ES + HKDF-512 (should be easy to implement, details needed)
• ECDH-ES + HKDF-256 (should be easy to implement, details needed)
• direct+HKDF-AES-256 (details needed)
• direct+HKDF-AES-128 (details needed)
• direct+HKDF-SHA-512 (details needed)
• direct+HKDF-SHA-256 (details needed)
• AES-MAC 128/64 (details needed)
• AES-MAC 256/64 (details needed)
• AES-MAC 128/128 (details needed)
• AES-MAC 256/128 (details needed)

Deprecated algorithms

Q	A
Bug report?	no
Feature request?	no
BC Break report?	no
RFC? / Specification	https://tools.ietf.org/html/draft-irtf-cfrg-webcrypto-algorithms-00
Version	1.2.0?

The data collector indicates what algorithm is deprecated or not.
This specification should be used as a reference for those algorithms.

Stop jwt-key-mgmt from tanking performance by setting required PHP version to >=7.2 or removing polyfill

So I was being stupid today and added a popular dependency without checking all it's dependencies. I pushed it to prod after testing and the servers tanked as a result of web-token/jwt-key-mgmt being insanely slow, even when not being used.

So what went wrong?
web-token/jwt-key-mgmt depends upon a polyfill for ext/sodium (paragonie/sodium_compat), and this results in paragonie/sodium_compat code being executed on every single request when the composer autoloader is used, thereby tanking the server performance. Performance dropped to ~65 %(17k to 11k rps).

Possible solutions
Removing the polyfill would be a good idea as it's only needed by those with an old PHP version. PHP 7.1 is no longer actively maintained and a polyfill can easily be added by those who need it, instead of forcing it on everyone. And I don't think it's as easy to stop a dependency from being installed(?).

Upping the minimum PHP version to 7.2 or removing the paragonie/sodium_compat dependency would solve this issue and remove the risk of ruining performance.

Remove \Iterator interface in favor of \IteratorAggregate

Q	A
Bug report?	no
Feature request?	no
BC Break report?	yes
RFC? / Specification	no
Version	all

The interface IteratorAggregate induces less complexity for the same result.

[Insight] Code should not be duplicated - in src/Bundle/…/Source/JWSBuilder.php, line 49

in src/Bundle/Signature/DependencyInjection/Source/JWSBuilder.php, line 49

The next 38 lines appear both in src/Bundle/Signature/DependencyInjection/Source/JWSBuilder.php:49 and src/Bundle/Signature/DependencyInjection/Source/JWSVerifier.php:51.

            $definition = new Definition(JWSBuilderService::class);
            $definition
                ->setFactory([new Reference(JWSBuilderFactory::class), 'create'])
                ->setArguments([$itemConfig['signature_algorithms']])
                ->addTag('jose.jws_builder')
                ->setPublic($itemConfig['is_public']);

            $container->setDefinition($service_id, $definition);
        }
    }

---

Posted from SensioLabsInsight

Documentation

Q	A
Bug report?	no
Feature request?	no
BC Break report?	no
RFC? / Specification	no
Version	1.0.0

• Components
• Bundle
• Console Application
• Security Recommendations
• Advanced Topics
  • Custom algorithm
  • Nested tokens
• Benchmarks
• Migration
  • From spomky-labs/jose

Creating an OKP with JWKFactory creates too long a private key for signing

Describe the bug
When using JWKFactory::createOKPKey(Ed25519) a 64 byte secret key is created. When used to sign a token, a SodiumException is thrown:

seed should be SODIUM_CRYPTO_SIGN_SEEDBYTES bytes

Note that the constant is defined as 32. Your tests for OKP creation and signing use a manually created 32 byte private key d.

PHP Version: 7.3.2

To Reproduce
Steps to reproduce the behavior:

$key = JWKFactory::createOKPKey('Ed25519');
$algorithmManager = AlgorithmManager::create([new EdDSA()]);
$jwsBuilder = new JWSBuilder(new StandardConverter(), $algorithmManager);

$jwtSigned = $jwsBuilder
            ->create()
            ->withPayload('')
            ->addSignature(
                $key,
                [
                    'crit' => ['exp', 'aud'],
                    'alg'  => ''EdDSA',
                ]
            )
            ->build();

Expected behavior
The token to be signed.

[Insight] Code should not be duplicated - in src/Component/…/Util/RSACrypt.php, line 230

in src/Component/Encryption/Util/RSACrypt.php, line 230

The next 28 lines appear both in src/Component/Encryption/Util/RSACrypt.php:230 and src/Component/Signature/Util/RSA.php:65.

     *
     * @return BigInteger
     */
    private static function exponentiate(RSAKey $key, BigInteger $c): BigInteger
    {
        if ($key->isPublic() || empty($key->getPrimes()) || empty($key->getExponents()) || null === $key->getCoefficient()) {
            return $c->modPow($key->getExponent(), $key->getModulus());
        }

        $p = $key->getPrimes()[0];
        $q = $key->getPrimes()[1];

---

Posted from SensioLabsInsight

Actual documentation

Q	A
Bug report?	no
Feature request?	no
BC Break report?	no
RFC? / Specification	no
Version	1.1.4

Hi!
I try to use the JWSVerifier to verify token signature. JWSVerifier::verifyWithKey() method needs some int $signature, but the documentation has no any information about this param (https://web-token.spomky-labs.com/components/signed-tokens-jws/jws-loading#serializer-and-verifier).

Also, the documentation say that if token signature is invalid - some exception will be thrown. But now method returns boolean false if token is invalid, otherwise true.

Is there an actual documentation?

Unrecognized option "jku" under "jose.keys.test". Did you mean "jwk"?

Describe the bug
When using the config for using a JKU key set I get an error that JKU is not a supported option.

To Reproduce
Steps to reproduce the behavior:

In httplu.yaml

httplug:
    plugins:
        cache:
            cache_pool: 'cache.app'
            config:
                default_ttl: 1800
    clients:
        jwk:
            factory: 'httplug.factory.guzzle6'
            plugins: ['httplug.plugin.cache']

In jose.yaml

jose:
    jku_factory:
        enabled: true
        client: 'httplug.client.jwk'
        request_factory: 'httplug.message_factory'
    keys:
        test:
            jku: # method
                url: '%env(TOEGANG_BASE_URI)%/oauth/certs'

Error:

(1/1) InvalidConfigurationExceptionUnrecognized option "jku" under "jose.keys.test". Did you mean "jwk"?

Installed package is the latest composer require web-token/jwt-framework (1.3.1).

Expected behavior
For the configuration to work.

Desktop (please complete the following information):
PHP 7.1, symfony 4.2

Thanks :)

How do I use this library?

Q	A
Bug report?	no
Feature request?	no
BC Break report?	no
RFC? / Specification	no
Version	1.0.78

I'm trying to use this library with Symfony 4 to enable JWT based authentication. I installed the bundle using composer require web-token/jwt-bundle as per the documentation, but beyond that I have absolutely no clue how to use it. I looked through the bundle code and saw a lot of console commands in there. I expected them to appear as you run bin/console, but no such luck.

There is nothing in the documentation about JWTs (not even how to create or validate one), no details about the services made available by the bundle or a configuration reference in the vein of how other bundles have. (e.g. doctrine).

So at this point I'm just going to move on and use this bundle instead (which seems to depend on an older version of this library).

Split off Symphony bundling

Right now, this package introduces a lot of dependencies which are only useful when you actually use the symphony bundle. I'd recommend to split that bundle of into a separate package to keep this one lightweight.

Question: What does `$component` mean?

Q	A
Bug report?	no
Feature request?	no
BC Break report?	no
RFC? / Specification	no

I have a generic question about the name of the $component argument one can pass to a Component/Checker/TokenTypeSupport.php implementation. What does $component mean in this context? It looks like it's the index of something referred to as a recipient on the token. Would it be better referred to as an $index? I'm not familiar enough with some of the more exotic forms of JWTs to guess from the name $component what that indicates. Perhaps I've overlooked something in the docs?

https://github.com/web-token/jwt-framework/search?utf8=%E2%9C%93&q=retrieveTokenHeaders&type=

Thanks for the insight! Love this library.

Leeway not defined for `exp` and `iat`

Q	A
Bug report?	no
Feature request?	no
BC Break report?	no
RFC? / Specification
Version	all

The exp and iat allow a small leeway to be defined (see https://github.com/web-token/jwt-framework/blob/v1.1/src/Component/Checker/IssuedAtChecker.php and https://github.com/web-token/jwt-framework/blob/v1.1/src/Component/Checker/ExpirationTimeChecker.php).

This feature is not described in the specification. Leeway is allowed for https://tools.ietf.org/html/rfc7519#section-4.1.5 but not for the other time based claims.

In general, the iat claim is used to verify that the token has not been issued too long ago. Leeway is not needed in this case.

The exp claim is used to define an expiration time and therefor the token should not be used after that time. If the token expired, there are other means (out of scope of this framework) that allow the issuance of a new token (e.g. refresh token grant for the OAuth2 framework protocol).

In the next major release, the leeway support for these claims have to be removed.

Remove fgrosse/phpasn1

Q	A
Bug report?	no
Feature request?	no
BC Break report?	no
RFC? / Specification	no
Version	v1.x

The library fgrosse/phpasn1 is only used for key management and RSA key conversions.
This library comprises lot of features that are not needed for this project.

It should be removed in favour of an internal implementation.

Documentation lists incorrect name for A256CBC-HS512

Q	A
Bug report?	no
Feature request?	no
BC Break report?	no
RFC? / Specification	https://tools.ietf.org/html/rfc7518
Version	N/A

Currently the documentation over at https://web-token.spomky-labs.com/ lists the usage of an encryption algorithm incorrectly named A256CBC-HC512.

The class in the code is correctly named A256CBCHS512, however the encryption algorithm in the section Supported Content Encryption Algorithms list it as A256CBC-HC512 (with a C rather than S).

Issue with JWSVerifier

Q	A
Bug report?	no
Feature request?	yes
BC Break report?	no
RFC? / Specification	no

Class Jose\Component\Signature\JWSVerifier is final and there is no JWSVerifier interface. This makes impossible to mock the class while testing a component has JWSVerifier as a dependency.

Question: Missing iss checker?

Q	A
Bug report?	no
Feature request?	no
BC Break report?	no
RFC? / Specification	no
Version	1.2.3

I'm new to this framework and to JWT in general. I was looking for an issuer checker under Component/Checker and did not find any. I was about to write one when I found IssuerChecker class as one of the stubs under tests. I may be missing something fundamental to the library - why doesn't the framework "officially" include an "iss" claims checker?

Nested token package

Q	A
Bug report?	no
Feature request?	yes
BC Break report?	yes
RFC? / Specification	no
Version	all

The nested token support should have its own package.
At the moment, the classes are provided by the encryption component. The classes should be moved in a dedicated package that will require the signature component.
Should be done for v2.0 only as it will cause a BC break (other package requirement).

Allow services to have custom tags

Q	A
Bug report?	no
Feature request?	yes
BC Break report?	no
RFC? / Specification	no
Version	1.x

The bundle creates numerous new services for keys, key sets, JWS Builders and so on.
Services can be retrieved using their ID (e.g. jose.key.xxxxxx).
Applications may need to tag those services to perform additional tasks e.g. to list them all or to manipulate them using a compiler pass.

It could be great to add the possibility to define custom tags directly using the bundle configuration and using the Configuration Helper.

Example:

jose:
    checkers:
        claims:
            checker1:
                claims: ['exp', 'iat', 'nbf', 'custom_checker']
                is_public: true
                tags:
                    my_app.security.claim_checker: {alias: 'security_check'}

Need PHP7.0 support for spomky jwt-framework

Hi,

I would love to use jwt-framework library but PHP versioning stops me.

Our server is on debian 9 stretch which is the latest stable release until now. I want to use those packages which are officially released by debian. In this case PHP7.0 is the official release for debian stretch.

PHP7.3 will be there in debian bluster but bluster is yet in test.

Composer require > PHP7.1
I would love to use this library but don't know how is it possible in a debian stable environment.

Claim Checker Manager should return only checked claims

Q	A
Bug report?	yes
Feature request?	no
BC Break report?	no
RFC? / Specification	no
Version	1.x

At the moment, the Claim Checker Manager returns all claims after checking (see ClaimCheckerManager.php#L82)
The problem is that is is not possible to know what claims have been checked or not and it becomes difficult to ignore the ones that have not been checked.

This method should only return the claims that have been checked.

google/wycheproof test vectors integration

See https://github.com/google/wycheproof

This repository contains a lot of test vectors to verify the cypher algorithms are correctly implemented.
These tests should be added to this project to detect any potential security issue.

OPCode optimization

Q	A
Bug report?	no
Feature request?	no
BC Break report?	no
RFC? / Specification	no
Version	all

Some function can be optimized during compilation process.

Request: Migration documentation update

It would be great if the documentation was a little more clear on how to make an implementation.

Right now I'm using this library as an example for an AWS Cognito implementation.
https://github.com/pmill/aws-cognito/blob/master/src/CognitoClient.php
It's using the old spomky lib, so I thought I would use the new one. But I find it very hard to follow the documentation.

For example, some code from the pmill cognito library:

    /**
     * @param CacheItemPoolInterface $cache
     */
    public function downloadJwtWebKeys(CacheItemPoolInterface $cache = null)
    {
        $url = sprintf(
            'https://cognito-idp.%s.amazonaws.com/%s/.well-known/jwks.json',
            $this->region,
            $this->userPoolId
        );
        $this->jwtWebKeys = JWKFactory::createFromJKU($url, false, $cache);
    }

What replaces the create from JKU? I Suppose it's this configuration: https://web-token.spomky-labs.com/bundle/jwk/keysets.html

jose:
    keys:
        key_name:
            x5u: # Method
                url: 'https://www.googleapis.com/oauth2/v1/certs'

If so, how is it used when I want to have a method like this one: (also from the pmill cognito library)

public function verifyAccessToken($accessToken)
    {
        $signatureIndex = null;
        $loader = new Loader();
        $jwt = $loader->loadAndVerifySignatureUsingKeySet($accessToken, $this->jwtWebKeys, ['RS256'], $signatureIndex);
        /** @var array $jwtPayload */
        $jwtPayload = $jwt->getPayload();
        $expectedIss = sprintf('https://cognito-idp.%s.amazonaws.com/%s', $this->region, $this->userPoolId);
        if ($jwtPayload['iss'] !== $expectedIss) {
            throw new TokenVerificationException('invalid iss');
        }
        if ($jwtPayload['token_use'] !== 'access') {
            throw new TokenVerificationException('invalid token_use');
        }
        if ($jwtPayload['exp'] < time()) {
            throw new TokenExpiryException('invalid exp');
        }
        return $jwtPayload['username'];
    }

Above I see a loader, that is verifying the signature using a key set. Is it done somewhere along the lines of this?

public function createJwtWebKeys(): JWKSet
{
    return JWKSet::createFromJson('{"keys": /* removed */');
}

public function verifyAccessToken(string $accessToken): bool
{
    // Signature?
    // The verifier is created like this: $this->verifier = $jwsVerifierFactory->create(['HS256']);
    // $this->jwkSet is set with createJwtWebKeys by manually pasting the response from aws from: https://cognito-idp.%s.amazonaws.com/%s
    return $this->verifier->verifyWithKeySet(JWS::create($accessToken), $this->jwkSet, 0);
}

Any info on migrating a situation like this would be great!

Thanks!

COSE

Q	A
Bug report?	no
Feature request?	yes
BC Break report?	no
RFC? / Specification	RFC8152, RFC7049 and other related specs.
Version	v2.0

Waiting for:

• https://github.com/Spomky-Labs/cbor-php

Actions to be performed:

• Add a MacAlgorithm interface for MAC algorithm.
• Partial IV

-out option removal

Q	A
Bug report?	no
Feature request?	no
BC Break report?	no
RFC? / Specification	no
Version	v2.0

The option --out or -o of console commands can be removed in favour of >, >>, &> or &>> of shells.

Proposal: ORM to test

I'm so sorry to disturb you, I would kindly ask you if you could test this library in your project!
https://github.com/javanile/moldable
With the purpose of knowing my project and understanding if it can be integrated into yours!
To thank you for your availability I am observing your project and giving a star

Install via composer

composer require javanile/moldable

I ask you if we can help each other

Use PHP-CS-Fixer instead of Style-CI

Q	A
Bug report?	no
Feature request?	no
BC Break report?	no
RFC? / Specification	no
Version	all from v1.2

Should also fix #134

Do we need JsonConverter?

Q	A
Bug report?	no
Feature request?	yes
BC Break report?	no
RFC? / Specification	no
Version	1.3.0 / 2.0.0

Just wondering why there is a JsonConverter interface with a StandardConverter implementation. I understand that some extra options like JSON_UNESCAPED_SLASHES and JSON_UNESCAPED_UNICODE are used in StandardConverter but I don't see why anyone would write a custom converter, what other ways are there to convert to JSON?

Take for example the JWSBuilder which has a withPayload method but it only accepts a string. Why not alter this method to accept both strings and arrays. In case of an array, use json_encode with the required options (mentioned above). This would cause no BC issues as a string is still accepted. You could deprecate the JsonConverter with a new v1 release and remove it in v2.

I'm happy to discuss and implement this change if you like.

Add Nested Tokens support

Q	A
Bug report?	no
Feature request?	yes
BC Break report?	no
RFC? / Specification	no
Version	1.0

Please add support for Nested Tokens