krizaka-users
Utilisateurs
Inscription, connexion, profils, clés d'API et rôles en service — avec un client typé pour les autres.
Le problème qu'elle supprime
L'inscription ressemble à un week-end. Jetons de reset, OAuth et JWT en font un trimestre.
L'inscription ressemble à un week-end. Viennent ensuite la vérification d'e-mail, les jetons de réinitialisation qui doivent expirer et ne servir qu'une fois, les comptes Google et GitHub à lier, les clés d'API, les rôles dans un JWT — et chaque autre service qui valide ce JWT à sa façon.
- Des liens de réinitialisation qui marchent deux fois, n'expirent jamais, ou dorment en clair dans la base — lisibles par quiconque a une sauvegarde.
- Une table d'utilisateurs qui gagne une colonne par fonctionnalité produit, jusqu'à ce qu'aucun autre produit ne puisse la réutiliser.
- Chaque service qui appelle le service d'identité à chaque requête — identité en panne, tout en panne.
Ce qu'elle fait
- Inscrire, vérifier, connecter par mot de passe ou Google/GitHub, réinitialiser — en service.
- Les JWT de session portent les rôles ; chaque autre service les vérifie localement.
- Un
UserDirectoryClienttypé, avec un jetonSERVICEet un cache par entrée.
Un service Spring Boot (ou le -core que vous embarquez) qui inscrit, vérifie, connecte par mot de passe ou Google/GitHub, réinitialise les mots de passe, émet des clés d'API et des JWT de session porteurs des rôles — et un client que chaque autre service appelle avec un jeton SERVICE.
Le hibou connaît chaque visage et ne garde aucun secret en clair : un jeton de réinitialisation sert une fois, est stocké en empreinte SHA-256 et meurt après 15 minutes ; un mot de passe est une empreinte BCrypt ; une clé de fournisseur est chiffrée en AES-256 avant de toucher le disque.
Décisions et compromis
Nous avons choisi
Les autres services vérifient le JWT de session localement (
krizaka-security), avec les rôles dans le jeton.Nous avons refusé
Appeler le service utilisateurs (introspection) à chaque requête.
Parce que
Une panne du service utilisateurs ne fait pas tomber la plateforme, et une requête ne coûte aucun aller-retour réseau.
Ce que cela vous coûte
Une session révoquée reste valide jusqu'à son expiration (
PT12Hpar défaut,IDENTITY_JWT_TTL).Nous avons choisi
Un profil = un thème plus des attributs définis par votre application — les réponses d'un formulaire d'onboarding dont vous fournissez le JSON Schema — stockés tels quels, jamais interprétés.
Nous avons refusé
Un modèle de profil figé avec des champs produit.
Parce que
Le service connaît des utilisateurs, pas votre produit ; les champs propres à Orazaka en sont sortis pour devenir ses réponses d'onboarding.
Ce que cela vous coûte
Votre code lit ses attributs avec ses propres valeurs par défaut.
Nous avons choisi
Un contrat publié (
krizaka-users-api), un client avec cache par entrée, et un-coreembarquable.Nous avons refusé
Une bibliothèque que chaque application branche sur ses propres tables.
Parce que
Un seul endroit hache les mots de passe et signe les jetons ; un correctif arrive une fois.
Ce que cela vous coûte
Une base PostgreSQL et RabbitMQ pour ses événements (
evt.user.registered,evt.password.reset).
En code
@Service
class InvoiceService {
private final UserDirectoryClient users; // SERVICE token on every call, per-entry cache
InvoiceService(UserDirectoryClient users) { this.users = users; }
String recipient(String userId) {
return users.getUser(userId).email();
}
String plan(String userId) { // attributes are YOUR onboarding answers, stored as given
return (String) users.getProfile(userId).attributes().getOrDefault("plan", "free");
}
}
# application.yml
krizaka.users.client:
base-url: http://users:8083
service-secret: ${IDENTITY_JWT_SECRET}
service-name: billing-service
cache-ttl: PT60SNe l'utilisez pas quand
- Vous avez déjà un fournisseur d'identité (Keycloak, Auth0, Entra ID) : gardez-le.
- Il vous faut SAML, du SSO d'entreprise ou l'authentification multifacteur : rien de cela n'est fourni.
- Il vous faut une révocation effective avant l'expiration du jeton.
Où elle en est
0.1.0 sur Maven Central (api, client, core). La 0.2.0 — schémas d'événements vérifiés contre leurs producteurs — est fusionnée et sort en novembre.
Publié
En cours
- Le BOM 0.2.0 gère cette brique en 0.2.0, non publiée : déclarez 0.1.0 explicitement jusqu'au BOM 0.3.0.krizaka-build#11
- Des jetons de session signés par ce service seul, vérifiés par les autres via son JWKS — plus de secret partagé.krizaka-platform-kit#11
L'adopter
<!-- BOM 0.2.0 names an unpublished 0.2.0 of this block: declare 0.1.0 until BOM 0.3.0 -->
<dependency>
<groupId>com.krizaka</groupId>
<artifactId>krizaka-users-client</artifactId>
<version>0.1.0</version>
</dependency>Dites-nous où ça coince.
Une brique est juste quand elle survit à votre code, pas au nôtre. Posez votre question dans le fil de la brique, proposez un changement comme idée, ou signalez un bug sur son dépôt — chaque décision de cette page reste ouverte à un meilleur argument.
Les autres briques
- Platform kitUn événement publié après le commit se perd au prochain crash.
- NotificationsUn e-mail envoyé dans une transaction annulée ne se rattrape pas.
- Facturation & créditsDébiter après, et le travail tourne à crédit. Débiter avant, et les échecs sont facturés.
- Build, BOM & kit de testLes POM parents dérivent — et un BOM Spring écrase en silence la version de Boot choisie.
- Krizaka UITrois produits, trois vocabulaires de jetons, 1 153 surcharges
light:dans une seule app.