Sessions, JWT et protection des accès
Sessions, JWT et protection des accès
Guide pratique pour gérer les sessions utilisateur, les jetons JWT (GitHub App) et sécuriser l'accès aux projets
Comprend les flows d’inscription/connexion/réinitialisation, la génération et la rotation des tokens GitHub App, le stockage sécurisé des sessions et les vérifications côté serveur.
Ce que couvre cette page
Session utilisateur
Gestion des sessions web : durée de vie, cookies sécurisés, visibilité côté client et invalidation.
JWT pour GitHub App
Génération d’un jeton JWT court, usage pour authentifier une installation d’application GitHub et transition vers une session utilisateur.
Protection des projets
Vérification d’accès aux projets, rôles, contrôle d’accès par token/session et prévention des accès non autorisés.
Stockage sécurisé
Bonnes pratiques : cookies HttpOnly, flags Secure, SameSite et stockage minimal côté client.
Expiration & rotation
Stratégies d’expiration courte, renouvellement contrôlé et rotation de tokens pour limiter l’impact d’un vol.
Flux d'inscription & crédits
Comportement à l’inscription (création de compte, attribution éventuelle de crédits de bienvenue).
Introduction
Ce guide explique, pas à pas et avec des recommandations pratiques, comment gérer les sessions des utilisateurs, comment fonctionne le jeton JWT utilisé pour le login via GitHub App, et comment protéger l’accès aux projets. Il s’adresse aux responsables produit, administrateurs et contributeurs non techniques qui doivent comprendre les flux utilisateur, les contraintes de sécurité et les actions à réaliser en cas de problème.
Rappel rapide
La connexion via GitHub App utilise un jeton JWT signé côté serveur (secret d’application) et conçu pour être court et unique : il sert uniquement à établir une session utilisateur contrôlée par le serveur.
Flux : S'inscrire (création de compte) — pas à pas
Étape 1 — Ouvrir le formulaire d'inscription
Dans l’interface d’inscription, renseignez les champs demandés (email, mot de passe, langue, acceptation des conditions). Vous pouvez aussi démarrer via OAuth (GitHub/GitLab) si proposé.
Étape 2 — Valider le formulaire
Soumettre le formulaire. Le système vérifie l’unicité de l’email et la conformité du mot de passe (longueur minimale, complexité si requise).
Étape 3 — Création du compte et retours
Après validation, le compte est créé. L’utilisateur voit une page de confirmation et une redirection possible vers le tableau de bord.
Étape 4 — Attribution de crédits initiaux (si applicable)
Si une offre de bienvenue est activée, des crédits peuvent être ajoutés automatiquement au compte. L’utilisateur est informé via l’interface (ex. “50 crédits bonus”).
Étape 5 — Vérifier la boîte mail (optionnel)
Si un e‑mail de vérification est envoyé, suivre les instructions pour valider l’adresse. Ce n’est pas toujours bloquant pour l’accès initial, mais recommandé pour la sécurité.
Flux : Se connecter (email/mot de passe ou OAuth) — pas à pas
Étape 1 — Choisir la méthode de connexion
Sur la page de connexion, sélectionner email/password ou un bouton OAuth (GitHub/GitLab).
Étape 2 — Authentification (email/password)
Entrer email et mot de passe, puis valider. Si les identifiants sont corrects, le serveur crée une session et l’utilisateur est redirigé vers son tableau de bord.
Étape 3 — Authentification (OAuth GitHub/GitLab)
Cliquer sur le bouton OAuth, autoriser l’accès sur la plateforme externe. Après autorisation, l’utilisateur est redirigé et, si nécessaire, un compte est créé automatiquement ou mis à jour. Des crédits de bienvenue peuvent être attribués.
Étape 4 — Session active et cookies
La session est matérialisée côté navigateur par un cookie sécurisé (HttpOnly, Secure, SameSite) ; les informations sensibles ne sont pas exposées au JavaScript client.
Étape 5 — Durée de session et expiration
La session a une durée limitée. À l’expiration, l’utilisateur doit se reconnecter ou suivre un mécanisme de renouvellement selon la politique du produit.
Étape 6 — Connexions multiples / appareils
Chaque appareil peut avoir sa propre session. Pour forcer la déconnexion globale, l’administrateur ou l’utilisateur peut révoquer les sessions actives (si la fonctionnalité est proposée).
Flux : Réinitialiser mot de passe — pas à pas
Étape 1 — Demander la réinitialisation
L’utilisateur clique sur “Mot de passe oublié”, entre son email, puis soumet la demande.
Étape 2 — Recevoir l'email de reset
Un message contenant des instructions (et un lien à usage unique et limité dans le temps) est envoyé à l’adresse fournie.
Étape 3 — Suivre le lien sécurisé
L’utilisateur clique sur le lien. Le système vérifie que le lien est toujours valide (non expiré, non utilisé).
Étape 4 — Définir un nouveau mot de passe
Saisir et confirmer le nouveau mot de passe. Après validation, la session peut être réinitialisée : l’utilisateur est connecté automatiquement ou invité à se reconnecter selon la politique.
Étape 5 — Mesures après reset
Recommander à l’utilisateur de vérifier les sessions actives et, si nécessaire, de révoquer les sessions ou tokens qui pourraient être compromis.
Flux : Connexion via GitHub App et jeton JWT (usage typique) — pas à pas
Étape 1 — L'utilisateur initie l'OAuth GitHub
L’utilisateur autorise l’application GitHub (ou effectue un login GitHub classique). L’application obtient les informations publiques nécessaires.
Étape 2 — Vérifier / créer l'utilisateur
Le serveur vérifie si l’utilisateur existe déjà (par identifiant GitHub ou email). Si non, un compte est créé et des crédits de bienvenue peuvent être attribués.
Étape 3 — Générer un jeton de connexion JWT court
Si l’utilisateur possède un mot de passe local et que l’usage le requiert, le serveur peut générer un jeton JWT signé, à usage unique et à très courte durée (par ex. quelques minutes). Ce jeton sert uniquement à valider une liaison ou à initier une session.
Étape 4 — Échanger le JWT contre une session
Le client envoie ce jeton au serveur pour obtenir une session authentifiée. Le serveur vérifie la signature du JWT, s’assure que le token n’est pas expiré et crée la session utilisateur.
Étape 5 — Expiration courte et usage limité
Le JWT d’initialisation doit expirer rapidement (p. ex. 5 minutes) et être strictement limité à l’usage prévu (login unique). Il ne doit pas servir comme token d’accès long terme.
Étape 6 — Installation GitHub App (si applicable)
Pour les repos connectés via une installation GitHub App, vérifier le statut de l’installation et utiliser des tokens d’installation distincts propres à l’installation pour accéder aux ressources GitHub.
Étape 7 — Requête serveur pour opérations sensibles
Chaque action sensible côté serveur doit vérifier à nouveau la session/permissions (cf. section “protection des projets”) avant d’effectuer des opérations sur un projet ou un dépôt.
Bonnes pratiques pour les jetons JWT GitHub App
Garder ces jetons extrêmement courts (quelques minutes) et ne les stocker nulle part côté client. Ils servent uniquement à établir une session et doivent être invalidés dès leur échange.
Conseil pour les sessions utilisateurs
Utilisez des cookies avec HttpOnly et Secure activés, et SameSite strict ou Lax selon le besoin. Évitez de stocker des données sensibles dans le stockage local ou le sessionStorage.
Piège fréquent : réutilisation de jetons
Ne réutilisez jamais un jeton JWT d’initiation comme preuve d’autorisation pour des requêtes API persistantes. Un tel token doit être à usage unique et changé rapidement.
Contrôles à mettre en place côté serveur (vérification et protection)
Vérifications serveur pour protéger l'accès aux projets
Étape 1 — Authentifier la requête
Vérifier la session (cookie) ou un token d’API valide. Prioriser les clés API pour les appels machine, les sessions pour les utilisateurs interactifs.
Étape 2 — Valider l'identité et le rôle
S’assurer que l’utilisateur est membre du projet et possède le rôle approprié (lecture, écriture, admin) avant d’autoriser l’action demandée.
Étape 3 — Vérifier l'origine des tokens GitHub App
Pour des actions liées à GitHub App, vérifier que l’installation est bien liée au projet et que le token d’installation est valide et non expiré.
Étape 4 — Vérifier l'expiration et la révocation
Toujours vérifier la date d’expiration des tokens et refuser les tokens expirés ou révoqués. Prévoir un mécanisme pour ré-authentifier l’utilisateur si nécessaire.
Étape 5 — Journalisation et surveillance
Loggez les tentatives d’accès sensibles, les échecs d’authentification et surveillez les activités anormales (tentatives répétées, patterns d’IP).
Étape 6 — Politique d'erreurs claire
Renvoyer des messages d’erreur génériques côté client pour éviter la fuite d’informations détaillées, tout en consignant les détails côté serveur pour l’analyse.
Comparaison rapide : Cookie de session vs Clé API vs JWT GitHub App
- Cookie de session : idéal pour utilisateurs web, gestion automatique de session, cookie HttpOnly.
- Clé API : idéal pour automatisation et agents, longue durée, à protéger strictement.
- JWT GitHub App : jeton court pour établir une session après OAuth/installation, usage unique, pas pour requêtes longues.
Rotation, stockage et expiration — recommandations pratiques
Comment gérer la rotation et le stockage des tokens
Étape 1 — Durées recommandées
- JWT d’initiation (GitHub App) : très court (ex. 5 minutes).
- Sessions web : durée raisonnable (ex. quelques heures à jours selon sensibilité).
- Clés API : durée longue, mais possibilité de révoquer/renouveler manuellement.
Étape 2 — Rotation automatique
Mettre en place une rotation régulière des clés API et des tokens d’installation GitHub si possible ; avertir l’utilisateur avant expiration/rotation.
Étape 3 — Stockage côté client
Stocker uniquement les cookies HttpOnly et éviter d’exposer des tokens dans le stockage local. Pour les intégrations machines, conserver les clés dans un coffre sécurisé.
Étape 4 — Invalidation et révocation
Permettre la révocation immédiate d’une session ou d’une clé API compromise via l’interface utilisateur ou l’administration.
Étape 5 — Sauvegarde post-compromission
En cas de fuite, révoquer les tokens affectés, forcer la réinitialisation des mots de passe si nécessaire et surveiller les logs d’activité.
Attention aux tokens long terme
Les clés ou tokens long terme exposés sont les plus dangereux : évitez de les transmettre sur des canaux non sécurisés (email non chiffré, messages publics) et privilégiez des coffres pour le stockage.
Scénarios et approches (Utilisateur vs Machine)
- Utiliser connexion par email/password ou OAuth.
- Sessions via cookies sécurisés.
- Tokens d’initiation (JWT) uniquement pour des échanges courts (ex. lier un compte GitHub).
- Vérifier toujours rôles et appartenance au projet avant d’autoriser une action.
Exemple de checklist avant déploiement (sécurité)
- Cookies : HttpOnly, Secure, SameSite définis.
- JWT d’initiation : durée très courte, usage unique.
- Clés API : mécanisme de révocation et d’affichage de dernière utilisation.
- Logs : journalisation des échecs d’authentification et des actions sensibles.
- Tests : scenarii de réinitialisation de mot de passe et de compromission simulée.
- Politiques : documentation pour les utilisateurs sur la gestion des accès et bonnes pratiques.
Automatiser les alertes de sécurité
Configurez des alertes qui détectent des volumes anormaux de tentatives de connexion ou les connexions depuis de nouveaux pays pour activer des vérifications supplémentaires (MFA, réauth).
Frequently Asked Questions
Besoin d'aide pour appliquer ces règles ?
Si vous avez des cas spécifiques (organisations, exigences compliance, MFA), contactez l’équipe pour adapter la configuration et les politiques d’accès.
Résumé : ce guide vous donne les étapes pratiques pour gérer l’inscription, la connexion, la réinitialisation de mot de passe, l’usage des JWT GitHub App et la protection des projets. Appliquez des durées courtes pour les JWT, stockez le minimum côté client, utilisez des cookies sécurisés, surveillez et rotatifiez les tokens et vérifiez systématiquement les permissions côté serveur.