ADR 0035 – jose pour les jetons de l'API
Statut : Décidée. Date : 30/09/2026. Applique la page « Protocole de synchronisation » (§12) et la page « Configuration Keycloak » (§8).
Contexte
Section intitulée « Contexte »L’API doit vérifier les jetons Keycloak (signature, expiration, audience, clés publiques récupérées par JWKS et renouvelées) et émettre le jeton PowerSync de 5 minutes, signé par sa propre clé et validé par le service PowerSync par JWKS. Le prototype l’a fait avec node:crypto, sans gestion de la rotation des clés.
Décision
Section intitulée « Décision »jose (licence MIT), sans dépendance : vérification par jwtVerify et createRemoteJWKSet, signature par SignJWT, publication de la clé publique par exportJWK. Algorithme RS256 imposé explicitement à la vérification. Le module auth de l’API est le seul à l’importer.
Alternatives écartées
Section intitulée « Alternatives écartées »node:cryptoécrit à la main : le prototype l’a fait ; la rotation de clés, le cache JWKS, le contrôle des algorithmes et des revendications seraient du code de sécurité à maintenir.@nestjs/jwtetpassport-jwt: enveloppentjsonwebtoken; plus de dépendances et un modèle d’authentification qui ne sert pas ici.
Conséquences
Section intitulée « Conséquences »Une dépendance d’exécution dans apps/api. Les tests injectent leur propre clé par un JWKS local : pas besoin de Keycloak pour tester l’API.
Stratégie de sortie
Section intitulée « Stratégie de sortie »Le code touche jose en deux endroits (vérification, émission). Un remplacement ne change ni les routes ni les revendications.