Implement 'jti' parameter for jwt to prevent replay attacks

[F21]

The 'jti' parameter in a JWT is a nonce to prevent replay attacks. This is currently optional in the spec and is not currently implemented in the library.

We should add support for checking the jti to see if it has been used. If so, the request should be denied.

[bshaffer]

Sounds reasonable. Is this something you want to submit a PR for?

[F21]

@bshaffer I would love to submit a PR, but would like some input on how we should expire the jti. The spec says that the jti cannot be reused for the duration of the exp parameter (once it has been used).

However, the question is how unique the jtis have to be. For instance, we can have a simple implementation where we have a list of jtis with their associated exps. Any jti that is on the list and not expired and reused will be denied.

However, we can also make it a bit "smarter" by linking the jti to the iss, sub, and aud parameters. So, for a jti to be denied, all of those parameters must match and the token should not be expired.

Once we have decided how to deal with that, implementation should be quite trivial.

Cheers 😄

[F21]

@bshaffer Let's reopen this for some further discussion as I think I would like to push an update to this.

Unfortunately, the spec doesn't give any guidance on how the JTIs should be generated:

"jti" (JWT ID) Claim

The jti (JWT ID) claim provides a unique identifier for the JWT. The identifier value MUST be assigned in a manner that ensures that there is a negligible probability that the same value will be accidentally assigned to a different data object. The jti claim can be used to prevent the JWT from being replayed. The jti value is a case-sensitive string. Use of this claim is OPTIONAL. 

So, the following approaches for generating a nonce may be considered valid:

• Have a counter that increments the nonce for each new jwt generated.
• Use the current timestamp as the nonce.
• Use the md5 hash of the jwt.

The above would cause collisions if 2 clients use the same scheme for generating the jtis.
Since the jtis are generated by the client, there is no way we can control their implementation.

I would like to modify the storage implementation to the following:

public function getJti($client_id, $jti, $jwt)

public function setJti($client_id, $jti, $jwt);

Instead of passing the jwt parameters to the storage implementations, we are passing the client_id jti and the decoded jwt.

This means that we could hopefully steer implementations to do the following:

• Match only jtis with client_ids. This prevents clients using simplistic nonce generating routines to affect other clients.
• Provide the decoded jwt, so that if required, the implementer can produce some sort of hash of the jwt to compare against if he feels he needs each nonce to be unique on a JWT basis.

I recommend something like this for generating the jti, but since the spec does not give any guidance, pretty much any generating method is valid:

$random_number = ... //generate using openssl_random_pseudo_bytes
$jti = hash('sha256', serialize($jwt) . $random_number);

In conclusion:

• Encourage storage implementers to check for nonce collisions on a client_id basis. One client's nonce should not affect another's. This is good practice in my opinion.
• If required, the jwt is provided if the implementer wants to check for jtis on a JWT basis.

Would love to hear your feedback on this! 😄

[Sicaine]

@F21 i'm just answering because i found it through google and someone else might find it:
I would only use uuid (in version 4). It reduces the risk of collisions to a level where i can trust it enough to generate unique ids.