🔐 2.5 Authentification et gestion des utilisateurs

Module 335 – Réaliser une application pour mobile

🎯 Objectif d'apprentissage

À la fin de ce chapitre, vous serez capables de :

• Comprendre les principes de base de l'authentification (identité, session, tokens)
• Identifier les différences entre authentification, autorisation et gestion des utilisateurs
• Expliquer le fonctionnement des tokens JWT, des sessions, et du stockage sécurisé
• Connaître les solutions modernes adaptées au mobile (Supabase Auth, Firebase Auth, Auth0, etc.)
• Gérer la persistance de connexion dans un contexte mobile offline-first

🤔 2.5.1 Introduction : pourquoi identifier ?

Dans une application mobile moderne, l’authentification permet de reconnaître un utilisateur et de lui offrir une expérience personnalisée.

Sans authentification, toutes les fonctionnalités doivent être accessibles à n’importe qui, sans distinction — ce qui est rarement souhaité.

2.5.1 Pourquoi identifier ?

Pour :

• Afficher des données personnelles
  → messages, notes, favoris, historique

• Protéger certaines fonctionnalités
  → commandes, paiement, configuration

• Synchroniser les données entre plusieurs appareils (cloud)

• Améliorer l’expérience utilisateur
  → retrouver profil, thème, préférences

👉 Sur mobile, un défi supplémentaire :
l’utilisateur s’attend à rester connecté, même si l’app est fermée plusieurs jours.

2.5.1 Authentification vs Autorisation

Ces notions sont souvent confondues :

• Authentification
  = vérifier l’identité de l’utilisateur

  “Êtes-vous bien Thomas ?”

• Autorisation
  = vérifier les droits d’accès

  “Thomas peut-il modifier ce document ?”

2.5.1 Gestion des utilisateurs

La gestion des utilisateurs englobe :

• création de compte
• connexion / déconnexion
• changement de mot de passe
• email de vérification
• gestion des rôles
• suppression de comptes

💡 Exemple concret :
Une application de notes affiche uniquement les notes du compte connecté :
impossible d’accéder à celles d’un autre utilisateur.

🔑 2.5.2 Les méthodes d’authentification modernes

Les applications mobiles supportent plusieurs méthodes d’authentification.
Chaque méthode a ses usages, ses avantages et son niveau de sécurité.

2.5.2 ① Email + mot de passe

La méthode la plus courante.

Fonctionnement :

1. L’utilisateur saisit email + mot de passe
2. L’app envoie la requête de connexion au serveur
3. Si les identifiants sont valides, le serveur renvoie un token de session
4. L’app stocke ce token en local (Preferences / SecureStorage)

➕ Avantages : simple, très répandu
➖ Inconvénients : nécessite une bonne gestion des mots de passe (hash, politique de sécurité…)

2.5.2 ② Magic Link

Méthode moderne, utilisée par Slack, Notion, etc.

Fonctionnement :

1. L’utilisateur saisit son email
2. Il reçoit un email avec un lien unique
3. Cliquer sur ce lien le connecte automatiquement

➕ Avantages : pas de mot de passe à retenir, expérience fluide
➖ Inconvénients : dépend entièrement de l’email, moins adapté à certains contextes “business”

2.5.2 ③ Social Login (OAuth)

Connexion via :

• Google
• Apple
• Facebook
• GitHub
• …

➕ Avantages :

• connexion ultra-rapide
• sécurité forte gérée par le fournisseur

➖ Inconvénients :

• dépendance à un acteur externe
• parfois rejeté dans les environnements sensibles (écoles, entreprises)

ℹ️ Cas particulier iOS
Apple oblige parfois à proposer “Sign in with Apple” si d’autres logins sociaux sont inclus.

2.5.2 ④ Biométrie (Face ID / Touch ID)

Utilisée pour déverrouiller un compte déjà connecté.

Ce n’est pas une authentification cloud, mais un verrou local.

➕ Avantages : très rapide, fluide pour l’utilisateur
➖ Inconvénients : doit être couplé à un compte déjà connecté (et à une auth serveur classique)

2.5.2 ⑤ Sessions avec tokens (JWT)

La majorité des apps mobiles utilisent aujourd’hui des tokens JWT (JSON Web Token), reçus après la connexion.

Authorization: Bearer <token>

• Le token encode des informations (id utilisateur, expiration, etc.)
• Il doit être stocké localement et renvoyé à chaque requête
• Un refresh token permet de prolonger la session de manière sécurisée
  → demander un nouveau token d’accès sans ressaisir les identifiants

ℹ️ Cette approche est au cœur de Supabase Auth, Firebase Auth, Auth0, etc.

🛡️ 2.5.3 Stockage sécurisé des sessions

Une application mobile doit pouvoir mémoriser la session d’un utilisateur même lorsque l’app est fermée.

Ce stockage doit être :

• persistant
• sécurisé

2.5.3 Où stocker un token ?

💬 Recommandation :
Toujours préférer un stockage sécurisé pour les tokens (access + refresh).

2.5.3 Bonnes pratiques – Sessions

• Ne jamais stocker de mot de passe en clair
• Utiliser un système de rotation (access token + refresh token)
• Vérifier l’expiration du token au lancement de l’app
• Token invalide → redirection vers l’écran de connexion
• Hors ligne → autoriser l’accès aux données locales tant que la session reste valide

💡 Exemple concret :
Supabase gère automatiquement la persistance de session,
mais l’app doit stocker les tokens pour pouvoir fonctionner hors ligne (au moins en lecture).

🥸 2.5.4 Solutions modernes d’authentification

La plupart des apps modernes ne recodent pas leur propre auth.
Elles utilisent des services spécialisés (BaaS ou Identity Providers).

2.5.4 Supabase Auth

• Entièrement open-source
• Basé sur PostgreSQL + JWT
• Supporte : magic links, passwords, OAuth
• Plugins officiels pour Capacitor, Flutter, React Native…
• Gestion automatique des :
  • sessions
  • tokens
  • expiration
• Compatible offline (via stockage local)

📝 Très bon choix pédagogique et pro pour projets modernes.

2.5.4 Firebase Auth

• Proposé par Google
• Très simple à prendre en main
• Supporte :
  • Social login
  • Email / mot de passe
  • Phone auth (OTP via SMS)
• SDK mobile très solide
• Gestion de base des utilisateurs (password reset, email verification…)

📝 Parfait pour un premier projet mobile.

2.5.4 Auth0 (niveau entreprise)

• Spécialisé en Identity & Access Management
• Très complet :
  • SSO
  • OAuth2
  • permissions avancées
• Idéal pour des environnements professionnels complexes
• Intégration plus lourde, mais très robuste

📝 Choix privilégié dans les grandes entreprises.

2.5.4 Comparatif synthétique

📲 2.5.5 Authentification en mobile offline-first

Sur mobile, l’expérience dépend fortement de la qualité de la connexion.

Les coupures sont normales :

• tunnels, ascenseur, trains
• parkings, zones rurales
• salles surchargées (ex. Aula du Banné 😉)

2.5.5 Objectifs d’une bonne app mobile

Une bonne app doit :

1. Continuer à fonctionner hors ligne
2. Maintenir la session le plus longtemps possible
3. Se reconnecter automatiquement quand le réseau revient

2.5.5 Objectifs d’une bonne app mobile

Contraintes :

• Session active même si l’app est fermée plusieurs jours
• Perte de réseau ≠ déconnexion
• Données locales toujours consultables
• Token expiré → tentative de refresh automatique

💡 Exemple concret :
Une app de notes doit rester utilisable offline, y compris pour consulter ou créer des notes, tant que la session locale est considérée comme valide.

💪 2.5.6 Stratégies robustes pour l’auth mobile

Exemple de stratégie d’auth robuste pour une app mobile moderne :

2.5.6 Étape 1 – Vérification de session au démarrage

🟦 1. Vérification de session au démarrage

Au lancement de l’app :

• l’app vérifie s’il existe un token valide en local
• si oui → l’utilisateur reste connecté
• sinon → redirection vers l’écran de connexion

2.5.6 Étape 2 – Rafraîchissement automatique

🟧 2. Rafraîchissement automatique du token

Les tokens JWT expirent (ex. après 1 heure).

Un refresh token permet de redemander un access token sans ressaisir le mot de passe.

Flux typique :

1. L’app utilise le token → l’API répond 401 Unauthorized
2. L’app tente un refresh en arrière-plan
3. Si le refresh réussit → nouvelle session transparente pour l’utilisateur
4. Si le refresh échoue → déconnexion

2.5.6 Étape 3 – Stockage sécurisé

🟩 3. Stockage sécurisé du token

Les tokens doivent être stockés via :

• Capacitor SecureStorage
• iOS Keychain
• Android Keystore
• Flutter flutter_secure_storage

🔐 Ne jamais stocker un token dans localStorage côté web :
risque d’accès via JavaScript (XSS).

2.5.6 Étapes 4 & 5 – Offline & déconnexion

🟧 4. Continuité hors ligne

Si l’utilisateur est hors ligne :

• l’app doit continuer à fonctionner sur les données locales (voir chapitre 2.4)
• les actions sont mises en file d’attente
• la synchronisation se fait quand le réseau revient

🟥 5. Déconnexion “gracieuse”

Si un token expire et que le refresh échoue (ex. mot de passe changé ailleurs) :

• nettoyage complet de la session stockée
• redirection vers la page de connexion
• message clair :

  “Votre session a expiré, veuillez vous reconnecter.”

2.5.6 En résumé

📝 À retenir
Une application mobile doit maintenir une session :

• stable
• sécurisée
• résistante aux interruptions réseau

Les BaaS modernes (Supabase, Firebase, etc.)
simplifient énormément cette logique.

🧩 2.5.7 Activités pédagogiques

🧪 Exercice 1 – Comparer les méthodes de connexion

Objectif : comprendre les avantages / limites des différentes méthodes.

➡️ Comparez mot de passe, OAuth et Magic Link.
➡️ Classez-les selon :

• sécurité
• rapidité
• expérience utilisateur
• facilité d’intégration

💬 Discussion : faut-il obliger les logins sociaux ?

2.5.7 Activité – Stockage de session

🗄️ Exercice 2 – Où stocker le token ?

Trois scénarios :

• Token stocké dans Preferences
• Token stocké dans SecureStorage
• Token stocké dans une base SQLite

➡️ Classez ces solutions du moins sécurisé au plus sécurisé et justifiez.
➡️ Expliquez pourquoi certaines solutions ne conviennent pas pour des tokens sensibles.

2.5.7 Activité – Workflow d’authentification

🔐 Exercice 3 – Schéma d’auth mobile

Réalisez un schéma complet du flux :

1. L’utilisateur saisit email + mot de passe
2. L’app envoie la requête à un service Auth
3. Le serveur renvoie un JWT + refresh token
4. L’app stocke les tokens localement
5. L’utilisateur accède à l’app
6. Lors d’un appel API → ajout du header
   Authorization: Bearer <token>
7. Token expiré → tentative de refresh
8. Échec → déconnexion propre

💬 Cet exercice prépare directement la section 2.6 (Supabase / Firebase).

🔗 2.5.8 Références et ressources

• Supabase Auth
  https://supabase.com/docs/guides/auth

• Firebase Authentication
  https://firebase.google.com/docs/auth

• Auth0 – Identity Platform
  https://auth0.com/docs

• OpenID & OAuth 2.0
  https://oauth.net/

• JWT (JSON Web Tokens)
  https://jwt.io

• OWASP Mobile Application Security
  https://owasp.org/www-project-mobile-security/