If a JWT token credential fails validation because it is expired is it deleted?
I ask because am making a login endpoint which will create a consumer if required and add a JWT token with an expiry dynamically. I am wondering if my system is going to accumulate old JWT tokens as sessions end and clients get new tokens. Should I make a delete call to the API each time I generate a new one?
Are you referring to client JWT Auth pattern? Kong’s db only stores JWT secret info, it does not store each passed jwt or cache anything of that nature. In the source it simply validates the passed JWT with the cached secret information on node of what the client uses to generate their JWT. Am I missing something?
Thanks for the answer. I think you are right I am still figuring out what behavior my endpoint will need. I think I will need to create a JWT credential if it is not there, but if the credential is there simply query it back and use that to generate the token.
I have created a docker login container which will receive a LDAP username and password, configure kong ACL’s and emit a JWT token that can be used for access. It is here if anyone is intrested. https://github.com/rmetcalf9/kong_ldap_login_endpoint
I have a question, I’m using kong by cluster. When I create JWT and use key and secret generate token, then client get token and send request by token. But Kong cluster have database cache time, maybe this node don’t have new JWT and then auth fail.
What can I do? or when I create JWT will sync in all cluster node? I‘m sorry I am a beginner.
So i use HS256 JWT. It comes with a symmetric key used to sign and validate JWT’s. This is stored in Kongs database. When you generate a token as an external client, Kong looks up and caches the JWT key + metadata info associated to that JWT token you sent. In the event you pass a jwt token and your Kong node cannot reach the database at the time to cache the jwt info then yes auth would fail. You can now set the database cache time to be indefinite though, and Kong recommends such a setting as they trust their cache logic more now than when it initially rolled out. Remember every Kong node has to talk to the database and cache relevant info from the database on an as needed basis.
One clarification(I am not sure if when Kong starts it takes the liberty to go ahead and cache all relevant jwt keys found on record to its local node cache, could be a perf improvement if they did so). Unlike oauth where they have to cache individual tokens and could not do such an optimization 
.
@JianmingXia you may find it helpful to review this documentation page https://docs.konghq.com/0.14.x/clustering/#multiple-nodes-kong-clusters to learn more about how Kong’s clustering works.
Thank you for reply. I had see the document.
I mean when I create a JWT in Node A. Then I send a request, the JWT had cached in Node A. But Node B had no data, the JWT will cached miss in Node B. And then have two scene:
I hope Node B can reload data from database when cached miss
If Kong Node B doesn’t have the information it needs to process a given request, it queries the datastore for the needed information, and then caches that information for the next time it receives a suitably similar request.
Thank you.
So When I create a new JWT or Consumer in one of the Kong nodes, other Kong nodes receive request, even no data in cache, Kong nodes will query datastore.
Only when I delete or update JWT or Consumer, the data in cache will have inconsistency data.
Only when I delete or update JWT or Consumer, the data in cache will have inconsistency data.
Nope! Kong handles cache invalidation correctly too (this is mentioned in the document I referred you too above).
I mean the inconsistency data is in short time