web-token / jwt-framework Goto Github PK
View Code? Open in Web Editor NEWJWT Framework
License: MIT License
JWT Framework
License: MIT License
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.
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:
web-token/jwt-signature-algorithm-none
: none
algorithmweb-token/jwt-signature-algorithm-rsa
: all RSxxx
and PSxxx
algorithmsweb-token/jwt-signature-algorithm-ecdsa
: all ESxxx
algorithmsweb-token/jwt-signature-algorithm-eddsa
: EdDSA
algorithmweb-token/jwt-signature-algorithm-hmac
: all HSxxx
algorithmsweb-token/jwt-encryption-algorithm-aeskw
: all AxxxKW
algorithmsweb-token/jwt-encryption-algorithm-aesgcmkw
: all AxxxGCMKW
algorithmsweb-token/jwt-encryption-algorithm-dir
: dir
algorithmweb-token/jwt-encryption-algorithm-ecdh-es
: all ECDH-ES
algorithmsweb-token/jwt-encryption-algorithm-pbes2
: all PBES2-HSxxx+AyyyKW
algorithmsweb-token/jwt-encryption-algorithm-rsa
: all RSA*
algorithmsweb-token/jwt-encryption-algorithm-aescbc
: all AxxxCBC+HSyyy
algorithmsweb-token/jwt-encryption-algorithm-aesgcm
: all AxxxGCM
algorithmsIt 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!
Q | A |
---|---|
Bug report? | no |
Feature request? | no |
BC Break report? | no |
RFC? / Specification | no |
Version | 1.0.0 |
Q | A |
---|---|
Bug report? | no |
Feature request? | yes |
BC Break report? | no |
RFC? / Specification | yes |
Version | x.y(.z) |
i want jwk to pem
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?
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?
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.
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.
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
andsrc/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
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.
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.
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.
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.
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
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).
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!
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
andsrc/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
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.
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.
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!
Q | A |
---|---|
Bug report? | no |
Feature request? | yes |
BC Break report? | no |
RFC? / Specification | no |
Version | 1.0 |
Please add support for Nested Tokens
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
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.
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
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:
Target for v2.0+:
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.
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.
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"
}
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:
The cache feature could be completely deprecated. Application will have to define their own cache strategy.
in src/Component/Encryption/Util/RSACrypt.php, line 230
The next 28 lines appear both in
src/Component/Encryption/Util/RSACrypt.php:230
andsrc/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
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.
Q | A |
---|---|
Bug report? | no |
Feature request? | no |
BC Break report? | yes |
RFC? / Specification | no |
Version | 1.x |
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?
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.
Q | A |
---|---|
Bug report? | no |
Feature request? | no |
BC Break report? | no |
RFC? / Specification | no |
Version | all from v1.2 |
Should also fix #134
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.
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.
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.
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.
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?
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).
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.
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'}
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:
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.
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.
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 | ? |
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 :)
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).
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.