public interface JwtAccessKeyCollector
JwtAccessKeyinstances for JWT validation.
It is expected that the
JwtAccessKeyinstances (and their corresponding
JwtValidateKeyinstances) are rotated. This minimises the impact of "leaked" keys (for whatever reason) from creating security problems.
Furthermore, in a clustered environment, co-ordinating the creation of
JwtAccessKeyinstances can become complicated. It is, therefore, possible to have multiple
JwtAccessKeyinstances in play, with the example following algorithm:
- A collect of keys is triggered for a particular instance in the cluster
- The instance retrieves all
JwtAccessKeyinstances from a central store, and identifies a new
- The instance creates the
JwtAccessKeyand stores it in the central store.
- Note: the active window for the
JwtAccessKeyshould be in the future. It should only be active after a time that all instances in the cluster will have collected the new
- The instance then includes the
JwtAccessKeyin its encoding
- Other instances in the cluster trigger a collect, and pull in the created
JwtAccessKeyfrom the central store.
- Should two instances in the cluster create a
JwtAccessKeysimultaneously, then both
JwtAccessKeyinstances can be arbitrarily used. This is ok as all instances should load both corresponding
- Note: this does come with the cost of extra computation on the consumers
to validate the JWT instances. However, this algorithm also works if the
cluster is co-ordinated to only create the one
JwtAccessKeyper time period (reducing this computation).
- Daniel Sagenschneider