Authentification et sessions
Comment SpineOS vous connecte via Google ou GitHub, combien de temps dure une session, et les réglages de cookies qui la sécurisent.
Fonctionnement de l'authentification
SpineOS utilise OAuth 2.0 pour l'authentification. Vous vous connectez avec votre compte Google ou GitHub. Il n'y a pas de mot de passe à créer.
Flux de connexion OAuth
Lorsque vous cliquez sur "Se connecter avec Google" ou "Se connecter avec GitHub" :
- Vous êtes redirige vers la page de connexion du provider (Google ou GitHub).
- Vous vous authentifiez auprès du provider et autorisez SpineOS à accéder à votre profil de base (e-mail et nom).
- Le provider renvoie un code d'autorisation à SpineOS.
- SpineOS échange le code contre vos informations de profil et crée ou met à jour votre compte.
- Une session sécurisée est créée et vous êtes redirige vers votre tableau de bord.
SpineOS ne reçoit ni ne stocke votre mot de passe Google ou GitHub. L'authentification est gérée par le provider OAuth.
Protection nOAuth
La recherche utilisateur se fait par oauthProvider + oauthId, pas par e-mail seul. Une recherche par e-mail seul est vulnérable à l'usurpation si un provider ne vérifie pas la propriété de l'adresse.
Un attaquant qui crée un compte Google ou GitHub avec votre adresse e-mail ne peut donc pas accéder à votre compte SpineOS. Votre identité est liée à votre compte provider OAuth spécifique, pas à votre e-mail.
Gestion des sessions
Après connexion, SpineOS crée une session côté serveur.
- Durée de session -- les sessions restent actives tant que vous utilisez la plateforme régulièrement. Les sessions inactives expirent automatiquement.
- Connexion unique -- vous pouvez être connecté sur plusieurs appareils simultanément.
- Révocation de session -- la déconnexion invalide immédiatement votre session côté serveur.
Sécurité des cookies
Paramètres des cookies :
| Paramètre | Valeur | Pourquoi |
|---|---|---|
| Préfixe | __Secure- / __Host- | Garantit que les cookies ne sont définis que via HTTPS |
httpOnly | true | Empêche JavaScript de lire le cookie |
secure | true | Le cookie n'est envoyé que via des connexions HTTPS |
sameSite | lax | Bloque les attaques de type cross-site request forgery |
Le préfixe __Host- ajoute une contrainte supplémentaire : le cookie doit être défini depuis l'hôte exact, ce qui empêche les attaques par sous-domaine.
Authentification API
Pour l'accès API, l'authentification se fait par clés API au lieu d'OAuth. Voir Authentification API pour les détails.
L'authentification par clé API inclut une limitation de débit : après 10 tentatives d'authentification échouées en 60 secondes depuis la même adresse IP, les tentatives suivantes sont temporairement bloquées pour prévenir les attaques par force brute.
Recommandations
- Utilisez un mot de passe fort sur votre compte Google/GitHub. La sécurité de SpineOS dépend de celle de votre provider OAuth.
- Activez l'authentification à deux facteurs sur votre compte Google ou GitHub.
- Déconnectez-vous sur les appareils partagés. Votre cookie de session reste valide jusqu'à déconnexion ou expiration.
Articles connexes
Données et confidentialité
Où SpineOS stocke vos données, ce qui est chiffré au repos et en transit, et qui peut accéder à un bureau une fois qu'il tourne.
Authentification API
Comment s'authentifier sur l'API REST publique : cookies de session pour Mission Control, clés API en Bearer pour l'accès programmatique.
Sécurité réseau
Comment SpineOS sécurise les connexions avec les headers CSP, la limitation de débit, TLS et l'authentification WebSocket.