JWT JTI Attribute

[kfox1111]

When federating with some other IDP's, they treat the optional JTI field as non optional. It looks like a very easy field we could add for compatibility. It just needs to be unique per token. Looks like some folks just use a sufficiently sized random number.

[maia-iyer]

Can confirm this is currently a requirement from Keycloak's built-in JWT authenticator, and would love for this feature to be implemented!

[MarcosDY]

Could you clarify which IDPs specifically require the JTI field? It would help us understand the compatibility needs better.

Regarding enabling this feature, would the following options make sense?

Globally: applied to all entries
Individually: configurable per entry
Selectively: based on certain fields (e.g., specific selectors)

Let us know what level of granularity you think is needed.

[kfox1111]

Keycloak for sure.

Its in the standard, so always adding it should work I think. but maybe on or off globally might be ok. cant think of a reason it needs to be per workload.

[sorindumitru]

Do you happen to have some links to documentation from Keycloak about how they use this?

One thing I'm concerned about is how this would interact with the agent cache. If a system uses the JTI as a form of replay protection the agent has no way of knowing that the token is "used up" and will continue to return it from the cache. Workloads won't have any way of controling this.

We need to see if adding support for the JTI claims needs any changes to how those tokens are cached. This might inform how we enable this, globally or at the entry/workload level.

[kfox1111]

I dont. The behavior of JTI should be defined in the rfc though here: https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.7

[sorindumitru]

We discussed this a bit today. Due to the JTI being used to for replay protection (i.e. only accept a specific JTI value once), we probably need to make sure that the agent doesn't cache SVIDs that have it set. This would be easier done with a flag on the entry, since this allows for configuring the, potentially fewer, workloads that need a JTI to have it in their JWTs and also bypass the agent cache while allowing other workloads to benefit from the cache.