Implement JWKS for IAM

Currently, our tokens are signed using a static key. If this key were to become compromised, we would need to generate a new key and communicate the corresponding public key to all consumers and providers and get them to use the new certificate to validate tokens. This could take some time and potentially cause an outage as consumers would not be able to validate tokens signed with the new key for some time.

TPP is an example of a system that is expecting to be able to use JWKS to validate the tokens.

The JWKS provides for a store of multiple keys that can be used to sign tokens and an endpoint for consumers/providers to obtain the corresponding public certificate. Keys can then be rotated whenever (can use a different key for different request if you really want) which means you can have short-lived keys that improve security.

The central work would be to provide the JWKS implementation in IAM, including:

defining the https://iam.domain/.well-known/jwks.json endpoint which returns a json object with a "keys" property that is an array of JWK objects.

A JWK object represents a public key and can be read and used by the consumers to validate token signatures. They are identified with a kid (key id) which is also references in the JWT token header.

See also OpenID Connect Discovery (https://openid.net/specs/openid-connect-discovery-1_0.html)

JWK RFC 7517 (https://datatracker.ietf.org/doc/html/rfc7517)

The IAM component then needs to be enhanced, perhaps with a UI (via admin suite) to manage the keys and use them with some defined strategy when signing the access tokens.

Then, there would need to be work on the Ensemble and NodeJS proxies to implement this JWKS way of obtaining the public key in order to verify the JWT.

Initially, the JWKS would only have the existing key in the store, maintaining compatibility with all participants, but also allowing those that which to use JWKS discovery to participate.

Further consultation with consumers/providers that use other products would be required.

Extra enhancements may include implementing an introspection endpoint such that a token validator can obtain more information about a token such as the name of the "sub" it was issued to.