Interface JwtAccessKeyCollector


  • public interface JwtAccessKeyCollector

    Collects JwtAccessKey instances for JWT validation.

    It is expected that the JwtAccessKey instances (and their corresponding JwtValidateKey instances) 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 JwtAccessKey instances can become complicated. It is, therefore, possible to have multiple JwtAccessKey instances in play, with the example following algorithm:

    1. A collect of keys is triggered for a particular instance in the cluster
    2. The instance retrieves all JwtAccessKey instances from a central store, and identifies a new JwtAccessKey is required.
    3. The instance creates the JwtAccessKey and stores it in the central store.
      • Note: the active window for the JwtAccessKey should be in the future. It should only be active after a time that all instances in the cluster will have collected the new JwtAccessKey (and corresponding JwtValidateKey instances).
    4. The instance then includes the JwtAccessKey in its encoding
    5. Other instances in the cluster trigger a collect, and pull in the created JwtAccessKey from the central store.
    6. Should two instances in the cluster create a JwtAccessKey simultaneously, then both JwtAccessKey instances can be arbitrarily used. This is ok as all instances should load both corresponding JwtValidateKey instances.
      • 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 JwtAccessKey per time period (reducing this computation).
    Author:
    Daniel Sagenschneider