Trying this one again. It provides but fixes the same that was in #20 (which addresses #19).

It also now adds the ability to set custom properties in the header and have the verification on the other end still work. This was achieved by adding to the constructor for the JWS object a way to pass the header as an array rather than just the two individual options. The constructor change was the least change to the JWS::load method. Alternatively we could do the getHeader/setHeader dance.

Hopefully my tests have it covered this time. Note that I didn't alter the doc strings for the JWS constructor as I didn't know the best way to do so, nor whether it was worth publicizing. It might be left as an exercise for the reader who wants custom header properties.

Please have a look and let me know if any changes are needed. Thanks.

Support for ES256, ES384, ES512 signer. On of the following PHP version required: php-5.4.26 php-5.5.10 php-5.6.0

The ASN.1 parser from phpseclib is needed for the detection of the curve. In future versions of PHP, this informations is provided by openssl_pkey_get_details. It might be better to add phpseclib to the suggest section of the composer file and adding a check if the ASN.1 parser is present.

Solves #15

The PHP core supports EC private keys for signing and verification. This change was introduced in January 2014. Currently this PHP versions support EC private keys: php-5.4.26 php-5.5.10 php-5.6.0

Release 6.0.4 introduced a change in HMAC::timingSafeEquals() which uses mb_strlen() to calculate string lengths when available, instead of strlen(). Unfortunately, this seems to have broken the function. The problem only becomes apparent in PHP 5.5 and below, since in 5.6.0 and onward it uses PHP's built-in hash_equals() function instead. Commenting out lines 54-57 in Namshi/JOSE/Signer/OpenSSL/HMAC.php fixes it for me:

    //if (\function_exists('mb_strlen')) {
        //$knownLength = \mb_strlen($known, '8bit');
        //$inputLength = \mb_strlen($input);
    //}

But the original commit by @cirpo which introduced this code indicates that strlen() also has problems. I'm not sure what the real fix should be...?

FWIW, here's how I am generating tokens:

$sessionId = 12345678;  //  (an integer)
$key = '********************************';   // (an MD5 hash)
$algo = 'HS256';

$jws = new SimpleJWS(['alg' => $algo]);
$jws->setPayload([
    'sub' => $sessionId,
    'iss' => 'My Company'
]);
$jws->sign($key);
$token = $jws->getTokenString();

And here is what I'm doing to validate them:

$jws = SimpleJWS::load($token);
if (!$jws->isValid($key, $algo)) {
    throw new \RuntimeException('Token is invalid!');
}

Any thoughts?

We've had trouble with openssl_pkey_get_private() and openssl_pkey_get_public() functions occasionally not recognizing well-formatted public and private keys, for reasons that are difficult to track down. To circumvent the need for these functions, we've allowed for phpseclib support of the RSA algorithms. The code is written according to the style and architecture of the existing library, and is fully tested. It will have no effect on existing code (i.e. it does not change the public API).

(Continuation of #48)

I added https://styleci.io/ config and the bridge for php-cs-fixer. I would suggest adding this repo to style-ci and future PR's can be checked for style issues automatically. Style issues can be fixed in accordance with this projects style guide simply by running php-cs-fixer fix . in the repo root directory.

If you would like to change the style requirements for this project, let me know (https://styleci.readme.io/docs/presets and https://styleci.readme.io/docs/fixers).

I also removed composer.lock as it was causing issues with travis. It isn't recommended to have this in library repos.

This fixes signature creation, the presently generated signature doesn't comply with the RFC and is rejected by other applications/libraries. The reason is that the signature is base64 encoded as a string instead of a hexidecimal representation of octets.

Convert signature to binary before base64 encode results in the expected signature as verified against the example in RFC 7515 and the http://jwt.io debugger.

Results may be validated with: echo -n "base64_encoded_header.base64_encoded_payload" | openssl dgst -sha256 -hmac "your_secret" -binary | base64 | tr -- '+=/' '- _'

As described in the draft 21, section 2 of JWT, the Base64 string should be safe and trailing = have to be omitted

(http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-21#section-2).

• Base64 class added to encode and decode according to the draft
• Tests added: test coverage is now 100%
• Test added to verify that old token will be correctly loaded
• Moved isExpired method from JWS to JWT
• constructors modified to use setHeader and setPayload methods

Fixed security floor. Always better to rely on a third party secure implementation rather than maintaining a separate one that just recently was noticed to be broken.

Hello guys, @jurriaan opened an issue in my library to notify that the I have some problems with my ECDSA signer.

Looking at your code I saw that you're basically doing the same thing as I, but you have another issue: you're ignoring openssl_verify() return by casting it bool. It's returning -1 (error) and if you run openssl_error_string() you'll get error:0906D06C:PEM routines:PEM_read_bio:no start line as return.

You can have more information in lcobucci/jwt#30. I'm working on a solution for that and I'll share with you guys :smile:

I'm using JOSE for handling JWTs in an API client. I would like to be able to check if the token is valid in terms of expiry without running a JWS::isValid. It would be nice if the JWS::isExpired was public. Happy to make a PR if there is a chance of it getting accepted.

Hi

I tried using ES512 but got the following error:

Fatal error: Uncaught InvalidArgumentException: phpseclib 1.0.0(LTS), even the latest 2.0.0, doesn't support PHP7 yet in /.../vendor/namshi/jose/src/Namshi/JOSE/Signer/OpenSSL/ECDSA.php:15

But phpseclib seems to be alright these days with PHP 7 (their builds pass on PHP 7 and 7.1, see https://travis-ci.org/phpseclib/phpseclib)

If I comment out the 2 version check blocks in Signer/OpenSSL/ECDSA.php then it seems to be working OK.

Is the block for PHP 7 still justified? If yes, could it at least be made more explicit in the README of this project? Also, would it be possible to emphasize the need to require phpseclib for ECSDA support in the same README?

Thanks

I got : "message": "Malformed UTF-8 characters, possibly incorrectly encoded", when trying to decode a token. $public_key = openssl_pkey_get_public('file://'.__DIR__.'/keys/public.pem'); if (! $signature->isValid($public_key, 'ES256')) { return new Response('Unauthorized', 403); } It's working fine when a generate the token using your library but when the token came from elsewhere (a ruby library) I got that error.

Any idea?

fix #111 As mentioned in RFC7519, iat is an optional claim. If iat is added in payload, token that does not contains iat will never pass signature verification.

According to JWT standard the 'iat' claim i optional. When decoding token (without 'iat') using SimpleJWS then verification of the signature fails. There is a function generateSigninInput in JWT class that return the input that the signature is verified against.

    public function generateSigninInput()
    {
        $base64payload = $this->encoder->encode(json_encode($this->getPayload(), JSON_UNESCAPED_SLASHES));
        $base64header = $this->encoder->encode(json_encode($this->getHeader(), JSON_UNESCAPED_SLASHES));
        return sprintf('%s.%s', $base64header, $base64payload);
    }

But when decoding token (without iat claim) with SimpleJWS, then 'iat' is automatically added to the decoded payload in setPayload method of SimpleJWS so the signinginput is different than was originally in token.

    public function setPayload(array $payload)
    {
        if (!isset($payload['iat'])) {
            $payload['iat'] = time();
        }
        return parent::setPayload($payload);
    }