Krizaka
Toutes les briques

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 UserDirectoryClient typé, avec un jeton SERVICE et 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.

La règle du hibou

Décisions et compromis

  1. 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 (PT12H par défaut, IDENTITY_JWT_TTL).

  2. 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.

  3. Nous avons choisi

    Un contrat publié (krizaka-users-api), un client avec cache par entrée, et un -core embarquable.

    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

javaInvoiceService.java · application.yml
@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: PT60S

Ne 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

xmlpom.xml
<!-- 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