You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The jti verification implemented here supports a variant of the spec, but is far to limited to a specific use case.
The spec (see https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32#section-4.1.7) stipulates that the claim should be a unique ID, but not an algorithm for generating such a unique ID. The supported verification here would enforce a specific algorithm, requiring an iat claim to be present as well as a key.
The iat claim is optional and unrelated to the jti claim in the spec and the key may either not exist in the case of an unsecured JWT or be unknown to the sender in the case of an asymmetric signing or encryption algorithm being used.
The iat claim is also defined as the integer number of seconds since epoch. This means that its use as a nonce to prevent replay isn't particularly valid. Given that it cannot be assumed that this is unique from an issuer, which may be issuing thousands of tokens with the same secret per second, adding this is quite limiting.
Further, the current implementation requires the developer to know the key, iat value for the JWT and also the algorithm used to generate the jti claim in order to decode the token.
The implementation provided for the jti verification is application-specific, so probably doesn't belong in a library such as this.
An alternative implementation might be to delegate verification of the uniqueness of the token to the application through a callback.
The text was updated successfully, but these errors were encountered:
The jti verification implemented here supports a variant of the spec, but is far to limited to a specific use case.
The spec (see https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32#section-4.1.7) stipulates that the claim should be a unique ID, but not an algorithm for generating such a unique ID. The supported verification here would enforce a specific algorithm, requiring an iat claim to be present as well as a key.
The iat claim is optional and unrelated to the jti claim in the spec and the key may either not exist in the case of an unsecured JWT or be unknown to the sender in the case of an asymmetric signing or encryption algorithm being used.
The iat claim is also defined as the integer number of seconds since epoch. This means that its use as a nonce to prevent replay isn't particularly valid. Given that it cannot be assumed that this is unique from an issuer, which may be issuing thousands of tokens with the same secret per second, adding this is quite limiting.
Further, the current implementation requires the developer to know the key, iat value for the JWT and also the algorithm used to generate the jti claim in order to decode the token.
The implementation provided for the jti verification is application-specific, so probably doesn't belong in a library such as this.
An alternative implementation might be to delegate verification of the uniqueness of the token to the application through a callback.
The text was updated successfully, but these errors were encountered: