This PR introduces changes made in the fork https://github.com/fproject/php-jwt to add support for JWKs, so that a fork is no longer needed. I didn't change the code from that repo apart from updating the docblock at the top of the JWK class, and breaking out the JWK tests into a new file JWKTest.php. Some spacing was also added to those tests to make the arrange/act/assert pattern clear.

I haven't done a ton of manual testing on this, but I assume since the fproject fork has been used, this is a working implementation (and the unit tests pass of course).

Fixes #70.

I know it's a bit weird to make a PR for someone else's code, but since there didn't seem to be any movement on #70 for making one I figured I'd start one so there can be a discussion about what further changes need to be made before this feature can be added to this repo.

Im using custom token auth on Firebase. I tried to generate token as the documentation said. But when i try to login in client side with (loginWithCustomToken(token)) method it gives an error below

{
 "error": {
  "errors": [
   {
    "domain": "global",
    "reason": "invalid",
    "message": "INVALID_CUSTOM_TOKEN"
   }
  ],
  "code": 400,
  "message": "INVALID_CUSTOM_TOKEN"
 }
}

I generate token with this code block as described in firebase documentation

$service_account_email = "USED_FROM_JSON_FILE"; //
$private_key = "USED_FROM_JSON_FILE";

function create_custom_token($uid, $is_premium_account) {
  global $service_account_email, $private_key;

  $now_seconds = time();
  $payload = array(
    "iss" => $service_account_email,
    "sub" => $service_account_email,
    "aud" => "https://identitytoolkit.googleapis.com/google.identity.identitytoolkit.v1.IdentityToolkit",
    "iat" => $now_seconds,
    "exp" => $now_seconds+(60*60),  // Maximum expiration time is one hour
    "uid" => $uid,
    "claims" => array(
      "premium_account" => $is_premium_account
    )
  );
  return JWT::encode($payload, $private_key, "RS256");
}

Would be nice to be able to decode the jwt without needing to verify the signature.

Eg, if you need to do additional processing when the jwt is expired.

Something like this:

public function decode($jwt, $verify = true)

Working with JWKS can have a serious impact on performance if the signing key is fetched on every request.

While fetching the Keys currently is left to the app specific implementation shouldn't fetching and caching the response from an external resource be something firebase/php-jwt should do?

Auth0 suggests to implement caching and .Net 6 seems to do it as well:

https://community.auth0.com/t/caching-jwks-signing-key/17654/2 https://github.com/auth0/node-jwks-rsa#caching

Taking all considerations into account and implement it here eliminates doing it over and over again.

Maybe (optionally) using https://packagist.org/packages/psr/simple-cache as a simple cache interface would be the way to go?

Suppose I get a jwt string xxxxxxxxxxxxxxx.xxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxx

Now, how will I verify this jwt ???

How will I convert this string back to an array to decode / verify it ? @bshaffer @mbleigh @ultrasaurus

Hello all, I have a problem in verifying the following signature in php-jwt, it is successfully verified using jwt.io website, the problem appears just when I try to verify it using php-jwt. I'm not sure if I missed something, could you tell me for any solution.

eyJhbGciOiAiSFMyNTYiLCJ0eXAiOiAiSldUIn0=.eyJ0aW1lIjoxNDI4OTQyMDcxLCJzdHIiOiJrYXJ0YWwiLCJsYW5ndWFnZSI6InRyIn0=.k4ZteQMHOs+43YxakNjuDfqevgFSmgwEykrgHxO1Uic=

The Firebase\JWT::decode() method signature changed for its second argument from string|array|resource to Key|array<Key>, which broke some of our CI builds at their static analysis stage. This has been introduced in v5.5.0 with https://github.com/firebase/php-jwt/commit/bc0df6440dfe4099266a44e99a2839a1856b8ec0. We're going to lock our version dependency at >=5.0 <5.5 but would like to know if this will be reverted or not ?

see #352 and #351

Builds off https://github.com/firebase/php-jwt/pull/365, but requires the changes (to be tagged in v6) for better security

• BC Breaking - requires the use of Firebase\JWT\Key when calling JWT::decode instead of passing in the $allowed_algs array.
• Key accepts a resource, string, or instance of OpenSSLAsymmetricKey
• JWK now requires the JWK Keyset to have alg set, which is an optional parameter. If there's a straight foward (and reliable) way to detect the algorithm from the other parameters in JWK, we should add this logic as well.

cc @paragonie-security

The specs allow for header paramters such as alg, jwk, jku, x5c, etc., which could have a determining factor in how the key is chosen.

This PR provides an interface for implementing such logic.

I'm storing jwt in a storage. of if client request with expired token which is in my storage then I want to reissue a jwt. but problem is how to get payloads from a expired jwt ?

I got this Fatal error: Uncaught exception 'Firebase\JWT\ExpiredException' with message 'Expired token' in I try to run try and catch, but it still come out Fatal Error.

try{
    $decoded = JWT::decode($jwt, $key, array('HS256'));
}catch(\Exception $e){
     echo 'Caught exception: ',  $e->getMessage(), "\n";
}

I am using PHP-5.4.36 How to catch this error? Thanks!

:robot: I have created a release beep boop

6.4.0 (2022-12-19)

Features

• add support for W3C ES256K (#462) (213924f)

This PR was generated with Release Please. See documentation.

The JWT.php decode() has a nonstandard check to verify that "the time according to the JWT on the issuing server" is not later than "the time on the machine that is verifying the JWT", w/in some apparently statically configured leeway. This presents a problem when the server that signs the JWT has a clock that is ahead of the machine calling decode(), where the code calling decode() is punished by getting an exception thrown, saying a perfectly valid JWT is invalid. The code calling decode() is expected to configure some arbitrary $leeway variable that is likely to break again or sacrifice security.

More details:

The firebase php-jwt JWT.php has this line: // Check that this token has been created before 'now'. This prevents // using tokens that have been created for later use (and haven't // correctly used the nbf claim). if (isset($payload->iat) && $payload->iat > ($timestamp + static::$leeway)) { throw new BeforeValidException( 'Cannot handle token prior to ' . \date(DateTime::ISO8601, $payload->iat) ); }

According to the RFC: The "iat" (issued at) claim identifies the time at which the JWT was issued. This claim can be used to determine the age of the JWT. Its value MUST be a number containing a NumericDate value. Use of this claim is OPTIONAL.

Notice that it says nothing about validating that this timestamp is not "in the future according to the validating machine's time". Enforcing this in the JWT.php code seems like an issue, as I've already seen (it looks like the Sign In With Google server is off by about 2 seconds with my machine). It's unreasonable to assume that it's a server maintainer's fault for getting out of sync with google's server's timestamp. It seems like it would be better, if the 'iat' is in the future, to use this to offset the timestamp, instead of throwing an exception.

The current workarounds I'm pondering are if I want to set the $timestamp static variable to this offset, to sleep() until 'iat' if it isn't too far in the future, or if I want to just bite the bullet and set the $leeway and cross my fingers that I guessed a good arbitrary leeway value.

The 'typ' and 'alg' headers are currently set by default, and cannot be overridden with the $head parameter. This change would still keep the default headers, but would allow developers to override it if they so choose.

One such use case would be to create a JWT of "typ": "passport", as per the stir/shaken requirements.

Why would you prevent overriding those headers? They're already set by default, developers should have the option to override them. Especially the "typ" one, what would be the point of that header if it always had to be "JWT"?

PR: https://github.com/firebase/php-jwt/pull/473

I tried using the auth keys published on Apple's website:

$signedTransactionJWT = $response['signedTransactions'][0];

$appleKeysText = file_get_contents('https://appleid.apple.com/auth/keys');

$jwks = json_decode($appleKeysText, true);
$keyset = JWK::parseKeySet($jwks);
$decodedTransactionPayload = JWT::decode($signedTransactionJWT, $keyset);

...but it horks with the following error:

Fatal error: Uncaught UnexpectedValueException: "kid" empty, unable to lookup correct key

I looked through the JWT::decode() method, and it's looking for a key id ("kid") in the header of the signed transaction JWT, but Apple doesn't provide a "kid" in the header of the signed transaction JWT. The structure of the header looks like this:

{
    "alg": "ES256",
    "x5c": [
        "MIIEMDCCA7agAwIBAgIQaPoPldvpSoEH0lBrjDPv9jAKBggqhkjOPQQDAzB1M...",
        "MIIDFjCCApygAwIBAgIUIsGhRwp0c2nvU4YSycafPTjzbNcwCgYIKoZIzj0EA...",
        "MIICQzCCAcmgAwIBAgIILcX8iNLFS5UwCgYIKoZIzj0EAwMwZzEbMBkGA1UEA..."
    ]
}

I'm an experienced developer in a hundred other topics, but this is my first time working with JWTs, so I'm doing my best to understand the various interacting pieces here.

How can I properly decode/verify the JWTs with x5c from Apple?