Authentification et Autorisation

1.1 Contexte

Ce document décrit l'architecture complète d'authentification et d'autorisation de la plateforme REWAPP. Il couvre les mécanismes de vérification d'identité, la gestion des sessions, les modèles de permissions et les mesures de protection contre les attaques.

L'authentification et l'autorisation constituent le premier rempart de sécurité de l'écosystème REWAPP, protégeant à la fois les données personnelles des utilisateurs et les transactions financières.

1.2 Objectifs de Sécurité

• Protection des identités

  Garantir que seuls les utilisateurs légitimes accèdent à leur compte

• Protection des transactions

  Sécuriser les opérations financières (virements, QR codes)

• Conformité réglementaire

  Respecter RGPD et PCI DSS pour les données bancaires

• Expérience utilisateur

  Maintenir une authentification fluide sans friction excessive

2.1 Vue d'Ensemble

L'architecture d'authentification REWAPP repose sur le protocole JWT (JSON Web Token) avec signature asymétrique RSA (RS256), garantissant l'intégrité et l'authenticité des tokens.

2.2 Flux d'Authentification Global

2.3 Points d'Entrée Authentification

3.1 Processus d'Inscription

3.1.1 Données Requises

3.1.2 Flux d'Inscription

1. 1

   Validation des données entrantes

   Format, unicité email

2. 2

   Hashage du mot de passe

   bcrypt avec 10 rounds

3. 3

   Création du compte utilisateur

   Statut: PENDING_VERIFICATION

4. 4

   Génération token de vérification

   UUID, validité 24h

5. 5

   Envoi de l'email de vérification

   Via SendGrid/Brevo

6. 6

   Retour succès

   "Email de vérification envoyé"

3.1.3 Vérification Email

Le lien de vérification contient un token UUID unique :

https://app.rewapp.fr/verify-email?token={verification_token}

À la validation :

• Statut compte passe à ACTIVE
• Token de vérification invalidé
• Email de bienvenue envoyé
• Connexion automatique possible

3.2 Processus de Connexion

3.2.1 Authentification Standard

{
  "email": "jean.dupont@example.com",
  "password": "MonMotDePasse123!",
  "deviceId": "device_xyz789",
  "deviceName": "iPhone 14 Pro"
}

{
  "success": true,
  "data": {
    "accessToken": "eyJhbGciOiJSUzI1NiIs...",
    "refreshToken": "eyJhbGciOiJSUzI1NiIs...",
    "expiresIn": 900,
    "tokenType": "Bearer",
    "user": {
      "id": "user_abc123",
      "email": "jean.dupont@example.com",
      "firstName": "Jean",
      "lastName": "Dupont"
    }
  }
}

3.2.2 Validation des Credentials

1. 1

   Recherche utilisateur par email

   Case-insensitive

2. 2

   Vérification statut compte

   ACTIVE requis

3. 3

   Comparaison mot de passe hashé

   bcrypt.compare()

4. 4

   Vérification IP/Device

   Détection anomalie

5. 5

   Si succès

   Génération tokens + log connexion

6. 6

   Si échec

   Incrémentation compteur tentatives

3.3 Politique de Mots de Passe

3.3.1 Exigences de Complexité

3.3.2 Caractères Spéciaux Acceptés

! @ # $ % ^ & * ( ) - _ = + [ ] { } | ; : ' " , . < > / ? `

3.3.3 Hashage et Stockage

4.1 Technologies Supportées

4.2 Flux d'Activation Biométrique

1. 1

   Demande d'activation

   Utilisateur connecté souhaite activer la biométrie

2. 2

   Vérification hardware

   Capteur présent et configuré

3. 3

   Prompt biométrique natif

   Confirmation d'identité

4. 4

   Génération biometric_token

   Token unique côté serveur

5. 5

   Stockage sécurisé

   Keychain (iOS) / Keystore (Android)

6. 6

   Association en base

   device_id + biometric_token

4.3 Flux d'Authentification Biométrique

{
  "deviceId": "device_xyz789",
  "biometricToken": "bio_token_encrypted_abc123",
  "biometricType": "FACE_ID"
}

4.4 Sécurité Biométrique

5.1 Structure des Tokens

5.1.1 Access Token (Courte Durée)

Structure Header :

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "key_2025_v1"
}

Structure Payload :

{
  "sub": "user_abc123",
  "email": "jean.dupont@example.com",
  "role": "USER",
  "permissions": ["read:points", "write:qrcode", "read:transactions"],
  "deviceId": "device_xyz789",
  "iat": 1732441800,
  "exp": 1732442700,
  "iss": "https://api.rewapp.fr",
  "aud": "rewapp-mobile"
}

5.1.2 Refresh Token (Longue Durée)

5.2 Génération et Signature

5.2.1 Clés RSA

• Type : RSA 2048 bits

  Minimum requis

• Rotation : 90 jours

  Automatisée

• Stockage clé privée

  Variables CapRover

• Publication clé publique

  JWKS endpoint

Endpoint JWKS :

https://api.rewapp.fr/.well-known/jwks.json

Réponse JWKS :

{
  "keys": [
    {
      "kty": "RSA",
      "kid": "key_2025_v1",
      "use": "sig",
      "alg": "RS256",
      "n": "0vx7agoebGcQ...",
      "e": "AQAB"
    }
  ]
}

5.3 Renouvellement des Tokens

{
  "refreshToken": "eyJhbGciOiJSUzI1NiIs..."
}

Processus de renouvellement :

1. 1

   Validation signature

   Vérification du refresh token

2. 2

   Vérification non-révocation

   Blacklist Redis

3. 3

   Vérification expiration

   Token encore valide

4. 4

   Génération nouveau access token

   Nouveau JWT

5. 5

   Rotation refresh token

   Nouveau refresh généré

6. 6

   Invalidation ancien token

   Ajout à la blacklist

7. 7

   Retour des nouveaux tokens

   Response au client

5.4 Révocation des Tokens

5.4.2 Blacklist Redis

Structure de la blacklist :

Clé : revoked_tokens:{token_jti}
Valeur : { revokedAt, reason, userId }
TTL : Durée restante du token original

6.1 Méthodes Disponibles

6.2 Configuration TOTP

6.2.1 Activation

1. 1

   Demande d'activation 2FA

2. 2

   Génération secret TOTP

   Base32, 160 bits

3. 3

   Génération QR code

   URI otpauth://

4. 4

   Affichage QR code + secret manuel

5. 5

   Scan avec application authenticator

6. 6

   Validation code TOTP

7. 7

   Génération 8 codes de récupération

8. 8

   Confirmation sauvegarde des codes

9. 9

   2FA activé ✓

URI otpauth format :

otpauth://totp/REWAPP:{email}?secret={secret}&issuer=REWAPP&algorithm=SHA1&digits=6&period=30

6.2.2 Validation TOTP

6.3 Backup SMS

Processus :

1. 1

   Demande code SMS backup

2. 2

   Vérification numéro de téléphone

3. 3

   Génération code 6 chiffres

   Validité 10 minutes

4. 4

   Envoi via Twilio

5. 5

   Saisie et validation

6.4 Codes de Récupération

• 8 codes alphanumériques de 10 caractères
• Format : XXXX-XXXX-XX
• Usage unique : chaque code ne fonctionne qu'une fois
• Régénération possible après authentification complète

A7B3-K9M2-XY
C4D8-P1Q5-ZW
...

7.1 Paramètres de Session

7.2 Gestion Multi-Devices

Chaque appareil connecté est identifié par :

• deviceId : UUID généré à l'installation
• deviceName : Nom de l'appareil (ex: "iPhone 14 Pro")
• deviceFingerprint : Hash de caractéristiques (OS, version, etc.)
• lastActiveAt : Dernière activité
• ipAddress : Dernière IP connue

{
  "success": true,
  "data": [
    {
      "deviceId": "device_abc123",
      "deviceName": "iPhone 14 Pro",
      "lastActiveAt": "2025-11-24T10:30:00Z",
      "ipAddress": "192.168.1.x",
      "isCurrent": true,
      "biometricEnabled": true
    }
  ]
}

7.3 Déconnexion à Distance

Effets :

• Révocation de tous les tokens de ce device
• Désactivation biométrie sur ce device
• Notification push (si possible) sur le device déconnecté

7.4 Détection d'Anomalies de Session

8.1 Principes RBAC

REWAPP implémente un modèle RBAC (Role-Based Access Control) hiérarchique avec héritage des permissions.

8.2 Rôles Utilisateurs (Application Mobile)

8.3 Rôles Partenaires (Dashboard Partenaire)

8.4 Rôles Administrateurs (Dashboard Admin)

8.5 Héritage des Permissions

9.1 Liste des Permissions

9.1.1 Permissions Utilisateur

9.1.2 Permissions Partenaire

9.1.3 Permissions Admin

9.2 Scopes OAuth2

Pour les intégrations tierces (notamment OpenBanking), REWAPP utilise des scopes OAuth2 :

9.3 Vérification des Permissions

Chaque endpoint API vérifie les permissions via un guard NestJS :

@UseGuards(JwtAuthGuard, PermissionsGuard)
@RequirePermissions('write:qrcode')
@Post('qr-codes/generate')
async generateQrCode() { ... }

Le middleware extrait les permissions du JWT et vérifie leur présence.

10.1 Protection Brute Force

10.1.1 Rate Limiting par IP

10.1.2 Compteur de Tentatives Échouées

Par compte utilisateur :

• 3 échecs : Affichage CAPTCHA obligatoire
• 5 échecs : Blocage temporaire 15 minutes
• 10 échecs : Verrouillage compte + email alerte
• Déblocage : Réinitialisation mot de passe ou intervention admin

10.2 Protection Contre l'Énumération

Messages d'erreur génériques pour ne pas révéler l'existence d'un compte :

10.3 Protection CSRF

Pour les endpoints sensibles du Dashboard Admin et Partenaire :

Méthode : Double Submit Cookie

• Cookie CSRF généré à la connexion
• Header X-CSRF-Token requis pour mutations (POST, PUT, DELETE)
• Validation côté serveur

SameSite: Strict
HttpOnly: false (accessible pour lecture JS)
Secure: true (HTTPS only)

10.4 Protection XSS

Content Security Policy (CSP) headers :

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; connect-src 'self' https://api.rewapp.fr

Headers de sécurité supplémentaires :

X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block

10.5 Protection Injection

• Requêtes paramétrées

  Prisma ORM avec requêtes préparées

• Validation des entrées

  Class-validator avec DTOs stricts

• Encodage des sorties

  Sanitization automatique

10.6 Protection Against Replay Attacks

Pour les opérations sensibles (QR code, virements) :

• Nonce unique par requête
• Timestamp avec fenêtre de tolérance (±5 minutes)
• JTI (JWT ID) unique pour chaque token

11.1 Flux de Liaison Carte Bancaire

REWAPP utilise OAuth2 Authorization Code Flow pour la liaison de carte bancaire via OpenBanking (Budget Insight, Plaid, Tink).

1. 1

   Utilisateur clique "Lier ma carte"

   Dans l'app mobile

2. 2

   Redirection vers fournisseur OpenBanking

   Consent screen

3. 3

   Autorisation de l'accès

   Données bancaires

4. 4

   Callback avec authorization_code

5. 5

   Échange code contre access_token

   Server-to-server

6. 6

   Stockage tokenisé

   Jamais de numéro de carte stocké

11.2 Sécurité de l'Intégration

11.3 Révocation OpenBanking

Actions effectuées :

• Révocation du token OAuth2 auprès du fournisseur
• Suppression des données tokenisées en base
• Arrêt de la détection automatique pour cette carte

12.1 Événements Audités

12.2 Format des Logs d'Audit

{
  "timestamp": "2025-11-24T10:30:00.000Z",
  "eventType": "AUTH_LOGIN_SUCCESS",
  "userId": "user_abc123",
  "actorId": "user_abc123",
  "ipAddress": "192.168.1.100",
  "userAgent": "REWAPP/1.0 (iOS 17.0; iPhone14,2)",
  "deviceId": "device_xyz789",
  "geoLocation": {
    "country": "FR",
    "city": "Paris"
  },
  "metadata": {
    "authMethod": "EMAIL_PASSWORD",
    "mfaUsed": false
  },
  "traceId": "trace_abc123"
}

12.3 Consultation des Logs

Dashboard Admin : Accessible aux ADMIN et SUPER_ADMIN

Filtres disponibles :

• Période (date début - date fin)
• Type d'événement
• Utilisateur concerné
• Administrateur acteur
• Résultat (succès/échec)

Export : CSV pour analyse, PDF pour audit officiel

13.1 Mot de Passe Oublié

Flux de réinitialisation :

1. 1

   Soumission email sur /forgot-password

2. 2

   Génération token reset (UUID, 1h)

3. 3

   Envoi email avec lien sécurisé

4. 4

   Clic sur le lien → formulaire

5. 5

   Validation nouveau mot de passe

6. 6

   Hashage et mise à jour en base

7. 7

   Révocation de tous les tokens actifs

8. 8

   Email de confirmation

13.2 Récupération 2FA

Si perte d'accès à l'application authenticator :

13.3 Compte Verrouillé

Causes : Tentatives échouées (10+), détection fraude, suspension admin

Procédure de déblocage :

1. 1

   Contact support ou lien email d'alerte

2. 2

   Vérification d'identité

3. 3

   Réinitialisation mot de passe obligatoire

4. 4

   Déblocage par équipe Support

5. 5

   Recommandation d'activer 2FA

14.1 Points Clés de Sécurité

• JWT RS256 - Tokens signés asymétriquement
• Access token court (15 min) - Limite l'impact d'un token compromis
• Refresh token rotatif - Nouveau token à chaque renouvellement
• Bcrypt (10 rounds) - Hashage robuste des mots de passe
• 2FA obligatoire Admin - Protection renforcée des accès privilégiés
• Rate limiting - Protection contre brute force et abus
• RBAC hiérarchique - Permissions granulaires par rôle
• Audit complet - Traçabilité de toutes les actions sensibles

14.2 Métriques de Sécurité

14.3 Documents Connexes

• Document 4.3 - Architecture Backend API
• Document 6.1 - Document de Sécurité
• Document 6.2 - Architecture de Sécurité
• Document 6.2.2 - Protection des Données (CSRF/XSS)
• Document 6.2.3 - Rate Limiting et Throttling
• Document 6.4 - Conformité PCI DSS
• Document 8.4 - Plan de Tests Sécurité