Flux de connexion

Flux d'authentification de bout en bout : depuis le formulaire côté frontend, en passant par le BFF et le service d'Auth, jusqu'à l'émission du JWT et la réponse au client.

Pourquoi la connexion est un flux clé

La connexion est probablement le premier flux que tout utilisateur exécute dans une application. C’est aussi l’un des plus sensibles : il met en jeu des identifiants, des jetons de sécurité et des décisions d’accès qui affectent l’ensemble du système.

Comprendre comment la connexion circule à travers l’architecture aide à voir comment les couches collaborent pour résoudre un cas réel de bout en bout.

Le flux étape par étape

sequenceDiagram
    participant U as Usuario
    participant FE as Frontend
    participant GW as API Gateway
    participant BFF as BFF
    participant AUTH as Auth Service
    participant DB as Users DB

    U->>FE: Ingresa email y contraseña
    FE->>FE: Validación básica del formulario
    FE->>GW: POST /auth/login
    GW->>GW: Rate limiting, logging
    GW->>BFF: Forward request
    BFF->>AUTH: Verificar credenciales
    AUTH->>DB: Buscar usuario por email
    DB-->>AUTH: Datos del usuario
    AUTH->>AUTH: Verificar hash de contraseña
    AUTH->>AUTH: Generar JWT (access + refresh)
    AUTH-->>BFF: Tokens + datos básicos del usuario
    BFF-->>GW: Respuesta formateada para UI
    GW-->>FE: 200 OK + tokens
    FE->>FE: Almacenar tokens, redirigir
    U->>FE: Ve el dashboard

Ce que fait chaque couche

Frontend

Affiche le formulaire de connexion
Valide que l’email a un format correct et que le mot de passe n’est pas vide
Envoie les identifiants en HTTPS à l’API Gateway
Reçoit les jetons et les stocke (généralement en mémoire ou dans un cookie httpOnly)
Redirige l’utilisateur vers la page principale

Important : le frontend ne stocke jamais le mot de passe. Il l’envoie une seule fois et travaille ensuite avec des jetons.

API Gateway

Reçoit la requête de connexion (cette route ne nécessite pas de jeton préalable)
Applique un rate limiting pour prévenir les attaques par force brute
Enregistre la tentative de connexion dans le journal d’accès
Achemine la requête vers le BFF

BFF

Reçoit les identifiants
Invoque le service d’authentification
Si l’authentification réussit, transforme la réponse au format attendu par le frontend
Si elle échoue, renvoie une erreur générique (sans révéler si l’email existe ou non)

Auth Service

Il s’agit du microservice spécialisé dans l’identité et l’accès :

Recherche l’utilisateur par email dans la base de données
S’il n’existe pas, renvoie une erreur d’identifiants invalides
S’il existe, compare le hash du mot de passe stocké avec le mot de passe reçu
En cas de correspondance, génère une paire de jetons JWT :
- Access token : durée de vie courte (15–30 minutes), contient les claims de l’utilisateur
- Refresh token : durée de vie plus longue (7–30 jours), permet de renouveler l’access token
Renvoie les jetons et les données de base de l’utilisateur (nom, rôle, permissions)

Base de données des utilisateurs

Stocke les données de l’utilisateur, notamment :

Email (unique)
Hash du mot de passe (jamais le mot de passe en clair)
Rôle et permissions
État du compte (actif, bloqué, en attente de vérification)
Métadonnées (dernière connexion, tentatives échouées)

Structure du JWT

L’access token JWT contient généralement :

{
  "header": {
    "alg": "RS256",
    "typ": "JWT"
  },
  "payload": {
    "sub": "user-123",
    "email": "usuario@ejemplo.com",
    "role": "admin",
    "permissions": ["read:orders", "write:orders"],
    "iat": 1705312200,
    "exp": 1705314000,
    "iss": "auth-service"
  }
}

Le jeton est signé avec une clé privée que seul l’Auth Service connaît. N’importe quel service peut vérifier la signature à l’aide de la clé publique correspondante.

Flux de renouvellement du jeton

Lorsque l’access token expire, le frontend utilise le refresh token pour en obtenir un nouveau sans redemander les identifiants :

sequenceDiagram
    participant FE as Frontend
    participant GW as API Gateway
    participant BFF as BFF
    participant AUTH as Auth Service

    FE->>GW: POST /auth/refresh (refresh token)
    GW->>BFF: Forward
    BFF->>AUTH: Validar refresh token
    AUTH->>AUTH: Verificar firma y expiración
    AUTH->>AUTH: Generar nuevo access token
    AUTH-->>BFF: Nuevo access token
    BFF-->>GW: Respuesta
    GW-->>FE: 200 OK + nuevo access token

Scénarios d’erreur

Identifiants incorrects

L’Auth Service renvoie une erreur générique : « Identifiants invalides ». On n’indique pas si l’email existe ou non, afin d’éviter l’énumération des utilisateurs.

Compte bloqué

Après N tentatives échouées (généralement 5), le compte est temporairement bloqué. Le service renvoie une erreur indiquant que le compte est bloqué et à quel moment une nouvelle tentative sera possible.

Jeton expiré

Le frontend détecte un 401 sur toute requête ultérieure et tente automatiquement de renouveler le jeton avec le refresh token. Si le refresh token a également expiré, il redirige vers la connexion.

Service d’Auth indisponible

Si l’Auth Service est hors service, le BFF renvoie un 503. Le frontend affiche un message « service temporairement indisponible » et permet de réessayer.

Considérations de sécurité

Les mots de passe ne sont transmis qu’en HTTPS
Ils sont stockés sous forme de hash avec sel (bcrypt, argon2)
Les jetons ont une expiration courte
Le refresh token peut être révoqué depuis le serveur
Le rate limiting protège contre la force brute
Les erreurs ne révèlent aucune information sur l’existence des comptes

Résumé

Le flux de connexion illustre comment toutes les couches de l’architecture collaborent pour résoudre un cas d’usage critique. Chaque couche a une responsabilité claire : le frontend gère l’expérience utilisateur, le Gateway protège l’entrée, le BFF orchestre et transforme, et l’Auth Service gère l’identité. La sécurité n’est pas un ajout tardif mais fait partie intégrante de la conception du flux.