Authentification et stockage sécurisé

L'application mobile utilise des comptes avec mot de passe : POST /auth/signup pour créer un compte, POST /auth/signin pour se connecter, POST /auth/password/forgot et POST /auth/password/reset pour un mot de passe oublié. Elle propose aussi la connexion Google (POST /auth/oauth/google) ; la connexion Apple a été retirée. POST /auth/2fa/verify confirme l'adresse email à l'inscription et sert d'étape de double authentification quand elle est activée. La connexion sans mot de passe par code email (POST /auth/login) n'est plus utilisée par le mobile ; le backend la conserve pour le web.

Le jeton de session est rangé dans le trousseau d'iOS ou le Keystore d'Android grâce à expo-secure-store. Cette page décrit les parcours, la vérification d'âge, le stockage et les défauts connus. Les règles côté serveur sont dans Authentification et 2FA et Sessions.

Fichiers principaux :

#Parcours de connexion

sequenceDiagram
  participant U as Citoyen
  participant S as SignInScreen
  participant H as useAuth
  participant A as Backend api auth
  U->>S: Email et mot de passe
  S->>H: signInWithPassword
  H->>A: POST /auth/signin
  alt 2FA inactive
    A-->>H: token, user
    H->>H: SecureStore puis setCredentials
  else 2FA active
    A-->>H: requiresTwoFactor, twoFactorMethod, userId, loginTicket
    S->>S: navigate Verify2FA
    U->>S: Code à 6 chiffres ou code de secours
    H->>A: POST /auth/2fa/verify avec code, userId, loginTicket
    A-->>H: token, user
    H->>H: SecureStore puis setCredentials
  end
  H-->>U: RootNavigator affiche les onglets

Toutes les fonctions de connexion de useAuth passent par applySession. Quand la réponse contient requiresTwoFactor et userId, elle enregistre la vérification en attente (setPendingTwoFactor) et renvoie userId, method, l'email, devOtpPreview et, pour la méthode APP, le loginTicket délivré par le backend après le mot de passe. SignInScreen et SignUpScreen le transmettent à Verify2FA en paramètre de route. Quand elle contient token et user, elle écrit le jeton et le profil dans SecureStore puis dispatche setCredentials, ce qui fait basculer RootNavigator vers les onglets.

SignInScreen vérifie le format de l'email (isValidEmail) et la présence du mot de passe avant l'envoi. Une erreur du backend, par exemple « Email ou mot de passe incorrect. », s'affiche dans un FormMessage annoncé par les lecteurs d'écran (accessibilityLiveRegion="polite").

#Création de compte

SignUpScreen demande :

Le backend envoie un code à 6 chiffres par email et renvoie requiresTwoFactor: true avec un identifiant de demande. L'écran ouvre Verify2FA avec purpose: 'signup'. Le compte n'est créé qu'à la vérification du code. Les deux cases sont aussi exigées avant d'utiliser Google depuis cet écran (canStart). Le backend refuse une inscription sans acceptTerms ni isAdultConfirmed à true.

Les liens vers les CGU et le règlement, ainsi que la phrase finale « En créant un compte, vous reconnaissez avoir lu la politique de confidentialité. », ouvrent l'écran Legal de la pile racine avec le document demandé (cgu, reglement ou confidentialite), sans quitter l'inscription (voir Navigation et écrans).

Le formulaire ne demande pas de tranche d'âge. La déclaration de majorité ne suffit pas pour jouer : l'âge est vérifié ensuite sur pièce d'identité (voir Vérification d'âge).

#Vérification du code

Verify2FAScreen reçoit userId, method, loginTicket, email, purpose et devOtpPreview en paramètres de route. verifyOtpCode(userId, code, loginTicket) ajoute le ticket au corps de POST /auth/2fa/verify quand il existe. Le backend n'accepte un code de l'application APP qu'avec un ticket valide pour ce compte ou une session du même compte (activation de la 2FA) ; sans ticket, il répond 401 « Connexion expirée ou incomplète : reconnectez-vous avant de saisir le code de votre application. ».

En développement (__DEV__), DevOtpHint affiche le code renvoyé par le backend dans devOtpPreview et permet de le recopier dans le champ. En cas de succès, verifyOtpCode enregistre le jeton et le profil et dispatche setCredentials. Si la réponse demande encore un second facteur (requiresTwoFactor, twoFactorMethod: 'APP', userId, loginTicket, cas d'un code email validé sur un compte protégé par application), l'écran vide le champ et se remplace par un nouveau Verify2FA avec la méthode APP et ce ticket. En cas d'erreur, le message du backend s'affiche sous le champ.

Contrairement au web, le mobile ne recharge pas le profil après la connexion : l'objet user stocké est le profil réduit renvoyé par la connexion. Il contient toutefois hasPassword et ageVerificationStatus, ajoutés par le backend. Les écrans Profil, Paramètres et Sécurité appellent eux-mêmes GET /user/profile.

#Mot de passe oublié

1. ForgotPasswordScreen envoie l'email à POST /auth/password/forgot. La réponse est identique que le compte existe ou non.
2. ResetPasswordScreen demande le code reçu, le nouveau mot de passe (mêmes règles qu'à l'inscription) et sa confirmation, et permet de redemander un code.
3. POST /auth/password/reset définit le mot de passe et révoque toutes les sessions du compte ; l'écran revient à SignIn par popTo('SignIn').

Un compte créé sans mot de passe (connexion par code sur le web ou Google) peut ainsi en définir un.

#Google

SocialAuthButtons.tsx est affiché sur SignInScreen et SignUpScreen.

Le backend vérifie la signature et l'audience du jeton (voir Authentification et 2FA). Il répond 503 quand GOOGLE_CLIENT_IDS est vide : le bouton est alors désactivé et le message du backend s'affiche dessous. Sans identifiant Google côté application, le bouton reste visible mais désactivé.

La connexion Apple a été retirée du mobile et du backend : plus de bouton, de mutation appleSignIn, de dépendance expo-apple-authentication ni de capacité usesAppleSignIn dans app.json.

Les identifiants client de l'application doivent figurer dans GOOGLE_CLIENT_IDS du backend, sinon le jeton est refusé avec une erreur 401. Un compte protégé par une 2FA par application reçoit un loginTicket et passe par Verify2FA avant d'obtenir sa session.

#Vérification d'âge

L'achat et le cadeau de tickets, l'échange de récompenses et l'achat de tickets à gratter exigent un âge vérifié par la Mairie (AGE_VERIFICATION_REQUIRED=true côté backend). VerifyAgeScreen.tsx envoie la pièce d'identité :

sequenceDiagram
  participant U as Citoyen
  participant V as VerifyAgeScreen
  participant P as expo-image-picker
  participant A as Backend
  V->>A: GET /user/identity
  A-->>V: status NONE ou REJECTED
  U->>V: Recto puis verso
  V->>P: Appareil photo ou galerie, base64
  P-->>V: Image JPEG ou PNG
  V->>A: POST /user/identity front, back
  A-->>V: status PENDING
  V->>V: setAgeVerificationStatus PENDING

Un encart dépliable « Protection de vos données » explique le chiffrement et l'usage du document avant l'envoi. Les textes d'autorisation affichés par le système sont déclarés dans app.json (plugin expo-image-picker). Le traitement côté Mairie, le chiffrement des images et leur effacement après décision sont décrits dans Authentification et 2FA et RGPD.

Après la connexion, RootNavigator ouvre VerifyAge automatiquement si le statut vaut NONE ou REJECTED (voir Navigation et écrans). La carte d'identité du profil (IdentityCard) affiche le statut et mène au même écran.

#2FA

Setup2FAScreen propose les deux méthodes :

La confirmation appelle verifyOtpCode(user.id, code). Le backend active la 2FA, révoque les autres sessions et renvoie un nouveau jeton, que l'application enregistre.

SecurityScreen affiche d'abord deux lignes « Connexion » : l'adresse email, qui mène à ChangeEmail, et le mot de passe, qui mène à ChangePassword. Il affiche ensuite l'état de la 2FA, mène à Setup2FA pour l'activer ou la reconfigurer et permet de la désactiver avec un code. Le champ peut rester vide si la session a moins de 15 minutes, seule situation où le backend accepte une désactivation sans code.

#Email et mot de passe du compte

Ces deux écrans de la pile racine sont ouverts depuis Paramètres, puis Sécurité.

Changer d'adresse email. ChangeEmailScreen se déroule en deux étapes :

1. le citoyen saisit la nouvelle adresse et, si le compte a un mot de passe (hasPassword), son mot de passe actuel ; l'écran refuse une adresse mal formée ou identique à l'actuelle, puis appelle requestEmailChange (POST /auth/email/change) ;
2. il saisit le code à 6 chiffres reçu sur la nouvelle adresse (en développement, DevOtpHint propose devOtpPreview) ; confirmEmailChange (POST /auth/email/confirm) renvoie l'adresse enregistrée, que patchUser reporte dans le slice auth et dans le stockage sécurisé.

Un bouton permet de revenir à la première étape pour corriger l'adresse. L'ancienne adresse reçoit une alerte de sécurité ; la session en cours reste valable.

Créer ou changer le mot de passe. ChangePasswordScreen demande le mot de passe actuel seulement si le compte en a un ; un compte créé avec Google ou par code email peut ainsi définir un premier mot de passe. Le nouveau mot de passe suit les règles affichées par PasswordRules et doit être saisi deux fois. changePassword (POST /auth/password/change) révoque toutes les sessions du compte et renvoie une nouvelle session, comme une connexion. applyRenewedSession de useAuth enregistre le nouveau jeton et le profil (avec hasPassword à vrai) dans SecureStore puis dispatche setCredentials : l'appareil reste connecté, les autres sont déconnectés.

patchUser(patch) fusionne un profil partiel dans le slice (updateUserProfile) et dans blocklucky_user_profile. Il sert aussi à l'écran Données personnelles après l'enregistrement du prénom et du nom.

#Stockage sécurisé

secureStorage.ts gère deux entrées :

Les écritures utilisent l'option keychainAccessible: SecureStore.WHEN_UNLOCKED_THIS_DEVICE_ONLY : sur iOS, l'entrée n'est lisible que lorsque l'appareil est déverrouillé et n'est jamais restaurée sur un autre appareil. Sur Android, expo-secure-store chiffre les valeurs avec une clé du Keystore. app.json désactive aussi la sauvegarde Android ("allowBackup": false), ce qui évite l'export des données de l'application dans les sauvegardes du système.

Toutes les erreurs de SecureStore sont avalées par des catch {} vides. Si l'écriture échoue, la session tient grâce au cache mémoire jusqu'à la fermeture de l'application, sans message. Sur la cible web d'Expo (Platform.OS === 'web'), le module se rabat sur localStorage (voir Stack et structure).

Le jeton est ajouté à chaque requête par prepareHeaders de baseApi.ts, qui appelle secureStorage.getToken(), et au handshake Socket.IO par socket.client.ts.

#Session au démarrage

Effets de bord à connaître :

• l'ancien jeton reste stocké et continue d'être envoyé dans l'en-tête des requêtes faites depuis l'écran de connexion, jusqu'à ce qu'une nouvelle connexion l'écrase ;
• hasSeenOnboarding n'est pas persisté non plus : l'introduction réapparaît à chaque démarrage à froid.

Pour restaurer la session, il faudrait, au montage de App, lire le jeton et le profil, dispatcher setCredentials, puis valider le jeton par GET /user/profile.

#Expiration et erreurs 401

Le baseApi mobile n'a pas de garde 401 : un jeton expiré ou révoqué n'entraîne pas de déconnexion. Les écrans connectés affichent alors des erreurs ou des données vides jusqu'à ce que l'utilisateur se déconnecte lui-même. C'est aussi le cas après une réinitialisation ou un changement du mot de passe depuis un autre appareil, qui révoque toutes les sessions. Le web, lui, efface la session à la première réponse 401 (voir État et appels API du web).

#Déconnexion

useAuth expose signOut et signOutEverywhere, qui appellent endSession(allDevices) :

1. POST /auth/logout avec { allDevices } ; le jeton part par prepareHeaders ; l'erreur est ignorée ;
2. secureStorage.clearSession() : suppression du jeton et du profil ;
3. logout dans le slice auth, ce qui ramène l'AuthStack ;
4. baseApi.util.resetApiState() pour vider le cache RTK Query.

La connexion Socket.IO n'est pas fermée à la déconnexion, contrairement au web : elle reste ouverte avec l'ancien jeton jusqu'à la fermeture de l'application. Côté serveur, la session est révoquée, donc une reconnexion de ce socket serait refusée.

#Comparaison avec le web

Les risques propres à chaque support sont analysés dans Navigateur et mobile.