Closed betimshahini closed 1 year ago
Moving the key-pair to a top-level store (to represent the key-pair for rollup) from user-app level. Suggested approach is a KV/DO namespace in Access.
This implies there will be a single key pair, right?
This implies there will be a single key pair, right?
A single keystore with a few key-pairs, until we do custom domains. Then, the custom domain can be the issuer for tokens to that domain, and therefore have their own key stores.
The keypairs in the store should be rotated from time to time (similar to certs), and we'd have to keep some of the old ones for overlap for validating previously issued tokens (again, similar to certs).
We can start with one keypair in the store for now, but we'll need to add support for rotation/addition at some point, so design/implement with that in mind.
Currently, we're creating a new key-pair to sign user JWTs on the first authorization between that user and an app. This makes it difficult to expose the jwks (JSON Web Key Set) store to be introspected publicly for the public signing key to be used for client-side verification of issued JWTs. Having the latter standardized brings us closer to conformance with the OIDC discoverability functionality ( #1565 ), specifically with providing
jwks_uri
at a static URL, corresponding to the issuer, eg.https://passport.rollup.id/.well-know/jwks.json
This can be enhanced later to be more granular (with WebFinger-based searching), but at a base level there should be a logical link between issuer URL and a location where a publicly-accessible jwks.json can be exposed.
This tracks the work of:
iss
field in JWTs to passport.This allows us to standardize the validation of the JWT based on the issuer field, and allow us to extend in the future.
Exposing of
/.well-known/jwks.json
will be tackled separately.