JTI Support

[tylerFowler]

I'd like to see the JTI (JWT ID) claim implemented so that I could, say, keep track of 'active' tokens out in the wild. And like the spec says it could be used to help prevent any replay attacks.

Are there any plans for this?

[omsmith]

You can add any claim you like in the payload. Is there something more you would want than that?

[tylerFowler]

I meant native support within the library. I can do it myself (and likely will for this project), I was just wondering if there were plans to have it in the library itself for ID generation.

[kareha]

Would like to see this too. Would like to set this in options.
Otherwise I would set everything in payload. Makes the options thing obsolete.
http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html#rfc.section.4.1.7

[junosuarez]

-1. the JWT spec intentionally only describes JTI by characteristics and not a specific identifier algorithm or format. I don't think a JWT library should make that decision for you. It might make more sense to expose it as a hook to provide an ID generator function, but in JavaScript there's not much benefit to adding api surface vs just specifying the claim via an object literal.

[jwahyoung]

@jden Although I agree with what you're saying, I do think it would be nice to expose jti as a property in the options object. Currently, to add a JTI, one must assign it as a property on their payload object - and while that works, it doesn't really fit with the rest of the claims interface. I think it could be more streamlined.

I'd like to do the following:

var token = jwt.sign(user, process.env.JWT_PRIVATE, {
    algorithm: 'RS256',
    issuer: 'example.com',
    expiresInMinutes: 60,
    identifier: uuid.v4()
});

What does everyone think?

[jaredpetersen]

@jedd-ahyoung I agree with your suggestion and I would really like to see this implemented.

[jfromaniello]

You can use payload.jti or options.jwtid now.