Authentification Flask - La méthode propre et sécurisée

Mettre en place une authentification propre dans Flask, ce n’est pas seulement afficher un formulaire de connexion. Il faut choisir le bon modèle de session, protéger les mots de passe, verrouiller les requêtes sensibles et décider très tôt si votre backend sert surtout une interface web, une API ou les deux. Je vais aller directement sur ce qui compte: la base technique qui tient la route, les compromis à connaître et les erreurs qui reviennent le plus souvent.

Choisir le bon modèle d’authentification pour votre application

Je commence toujours par là, parce qu’un mauvais modèle complique tout le reste. Dans une application Flask, on peut authentifier un utilisateur avec une session classique, avec un jeton d’accès, ou via un fournisseur d’identité externe. Le bon choix dépend moins de la mode du moment que de l’usage réel: application web rendue côté serveur, SPA, mobile, back-office interne ou API publique.

Pour un site web traditionnel, la session cookie reste le chemin le plus simple et le plus robuste. Pour une API consommée par plusieurs clients, le modèle par jeton devient plus naturel. Et si vous devez gérer du SSO ou déléguer la connexion à un tiers, je regarde plutôt du côté d’OIDC ou d’un service d’identité dédié. En pratique, je ne pars jamais d’un JWT par réflexe: je pars du besoin de transport, de révocation et de maintenance.

• Session cookie si votre frontend et votre backend vivent ensemble et que le navigateur reste le client principal.
• Bearer token si vous avez un client mobile, une SPA découplée ou des intégrations externes.
• OAuth2/OIDC si vous ne voulez pas porter vous-même toute la logique d’identité.

Ce choix initial est important, parce qu’il détermine la forme de votre protection CSRF, votre stratégie de révocation et même votre manière de tester l’application. Une fois le modèle tranché, la couche la plus simple à mettre en place proprement dans Flask passe souvent par Flask-Login.

Poser une base propre avec Flask-Login

Flask-Login reste, à mes yeux, la brique la plus lisible pour gérer l’état de connexion dans une application Flask. La documentation de Flask-Login précise qu’il stocke l’identifiant de l’utilisateur actif dans la session et qu’il gère aussi le cas “remember me”. C’est utile, parce que vous gardez la main sur la base de données, le schéma utilisateur et la logique métier, sans réinventer la gestion de session.

Les briques minimales

Je mets toujours en place les mêmes éléments: un `LoginManager`, un modèle `User` avec `UserMixin`, un callback `user_loader` et des helpers pour hacher puis vérifier les mots de passe. Ce socle suffit pour couvrir le login, le logout et la protection des routes privées.

from flask_login import LoginManager, UserMixin, login_user, login_required, logout_user
from werkzeug.security import generate_password_hash, check_password_hash

login_manager = LoginManager()
login_manager.login_view = "auth.login"

@login_manager.user_loader
def load_user(user_id):
    return User.query.get(int(user_id))

class User(UserMixin, db.Model):
    id = db.Column(db.Integer, primary_key=True)
    email = db.Column(db.String(255), unique=True, nullable=False)
    password_hash = db.Column(db.String(255), nullable=False)

    def set_password(self, password):
        self.password_hash = generate_password_hash(password)

    def check_password(self, password):
        return check_password_hash(self.password_hash, password)

Le flux de connexion

Le flux que je préfère reste volontairement sobre. L’utilisateur soumet son email et son mot de passe, je charge le compte, je vérifie le hachage, puis j’appelle `login_user`. Pour une application de production, j’ajoute aussi une route de déconnexion en `POST`, pas en `GET`, pour éviter les mauvaises surprises.

@auth_bp.post("/login")
def login():
    form = LoginForm()
    if form.validate_on_submit():
        user = User.query.filter_by(email=form.email.data).first()
        if user and user.check_password(form.password.data):
            login_user(user, remember=form.remember_me.data)
            return redirect(url_for("dashboard"))
    return render_template("login.html", form=form)

@auth_bp.post("/logout")
@login_required
def logout():
    logout_user()
    return redirect(url_for("auth.login"))

J’aime aussi garder un message clair en cas d’échec de connexion, via le système de flash messages de Flask, parce qu’un utilisateur qui ne comprend pas ce qui bloque finit toujours par réessayer au hasard. Une fois cette base en place, il faut surtout éviter de casser la sécurité avec des réglages de session trop permissifs.

Sécuriser les formulaires et les sessions sans compliquer le code

La partie souvent sous-estimée n’est pas la connexion elle-même, mais tout ce qui l’entoure. La documentation de Flask rappelle qu’une session est un cookie signé: l’utilisateur peut voir le contenu, mais il ne peut pas le modifier sans votre `SECRET_KEY`. En pratique, cela veut dire deux choses: une clé secrète longue et imprévisible, et une configuration de cookies cohérente avec le contexte de déploiement.

Protéger la session

Je définis la clé secrète hors du dépôt, idéalement dans une variable d’environnement, puis j’impose les options de cookie qui vont dans le bon sens. Sur une application exposée en HTTPS, je préfère expliciter les réglages au lieu de compter sur des valeurs implicites.

app.config["SECRET_KEY"] = os.environ["SECRET_KEY"]
app.config["SESSION_COOKIE_HTTPONLY"] = True
app.config["SESSION_COOKIE_SECURE"] = True

Si votre flux le permet, je regarde aussi `SameSite` pour réduire l’exposition aux requêtes croisées. Ce n’est pas un substitut au reste, mais c’est un garde-fou utile dans un backend qui vit sur le web public. Et si vous devez faire tourner la clé, prévoyez une rotation progressive plutôt que de tout casser d’un coup.

Lire aussi : NODE_ENV en Node.js - Maîtrisez la configuration de votre API

Bloquer le CSRF au bon endroit

Dès qu’une authentification s’appuie sur des cookies, le CSRF devient un sujet central. Flask le rappelle clairement: une requête déclenchée depuis un site tiers peut embarquer le cookie de session sans que l’utilisateur s’en rende compte. Sur les routes qui modifient l’état, je mets donc un jeton CSRF systématiquement, que ce soit avec Flask-WTF ou avec un mécanisme équivalent.

  {{ form.csrf_token }}
  ...

Pour les appels AJAX, j’envoie le jeton dans un en-tête dédié, par exemple `X-CSRFToken`. Je ne considère jamais qu’une API JSON est automatiquement à l’abri du CSRF juste parce qu’elle ne rend pas de HTML. Si l’auth repose sur des cookies, la protection doit suivre la même logique.

Côté mots de passe, je reste strict: jamais de texte en clair, jamais de hash rapide type SHA-256 pour ce cas précis. OWASP recommande un algorithme adaptatif comme Argon2id, avec une configuration qui coûte suffisamment cher à l’attaquant; à défaut, bcrypt ou PBKDF2 restent des options sérieuses. Pour partir sur une base saine, je préfère un hachage lent et salé plutôt qu’une solution maison “simple” qui vieillit mal.

Une fois ces garde-fous en place, la vraie question devient celle du transport de l’identité: cookie de session, jeton, ou délégation complète à un fournisseur externe.

Sessions, jetons ou SSO pour une API

Dans un backend Flask qui expose aussi une API, je sépare très vite les cas d’usage. Une session cookie protège très bien une interface web servie au navigateur. Un jeton devient plus logique pour un client mobile, une intégration tierce ou une architecture où le frontend et le backend sont réellement découplés. Le piège, c’est de croire qu’un JWT règle tout: un format de jeton n’est pas une stratégie de sécurité à lui seul.

Et pour une SPA, je ne fais pas semblant d’ignorer le sujet du stockage: un token dans `localStorage` simplifie le démarrage mais augmente l’impact d’une faille XSS; un token en cookie remet le CSRF dans l’équation. Il n’y a pas de cadeau gratuit, seulement des compromis plus ou moins maîtrisés.

Les erreurs qui coûtent cher en production

La plupart des incidents que je vois en authentification viennent d’un petit nombre d’erreurs répétées. Elles paraissent banales au début, puis elles deviennent très chères quand l’application grossit ou quand un vrai usage métier arrive.

• Stocker les mots de passe en clair ou avec un hash trop rapide : c’est l’erreur la plus grave, et elle est encore trop fréquente dans les prototypes qui “passent en production” trop vite.
• Confondre authentification et autorisation : le fait d’être connecté ne veut pas dire qu’on peut accéder à une ressource, modifier un profil ou voir un espace admin.
• Oublier `user_loader` : sans rechargement correct de l’utilisateur depuis la session, Flask-Login ne peut pas reconstruire l’état de connexion proprement.
• Garder la clé de développement : un `SECRET_KEY` faible, partagé ou commité dans le dépôt suffit à fragiliser toutes les sessions signées.
• Faire des actions sensibles en `GET` : déconnexion, suppression, changement de mot de passe ou modification de rôle doivent rester sur des requêtes protégées.
• Oublier l’expiration et la révocation : le “remember me” est utile, mais il ne doit pas rendre un compte administrateur permanent par accident.

Quand je teste ce type de fonctionnalité, je vérifie toujours les mêmes parcours: inscription, connexion réussie, mauvais mot de passe, accès à une route protégée, déconnexion, puis retour sur une page privée après expiration de session. Dans une API, j’ajoute aussi un test de rejet sans jeton CSRF, et un test d’accès refusé pour un utilisateur connecté mais non autorisé. Le point important n’est pas de couvrir “beaucoup de cas”, mais de couvrir les cas qui cassent réellement la sécurité.

Si vous avez un doute sur le bon comportement d’une route, posez-vous une question simple: est-ce que je veux un `302` vers la page de login, ou un `401/403` explicite pour un client API ? La réponse vous évite beaucoup de bricolage plus tard.

Le point de départ que je choisirais pour un projet sérieux

Si je devais démarrer un projet Flask aujourd’hui, je partirais sur une base assez simple, mais stricte: Flask-Login pour la session web, Flask-WTF pour les formulaires, un hachage adaptatif pour les mots de passe, et une configuration de cookies durcie dès le début. Pour un backend qui sert aussi une API, je séparerais clairement les routes HTML et les routes JSON, au lieu de mélanger les deux dans un seul flux flou.

• Application web classique: Flask + Flask-Login + Flask-WTF + SQLAlchemy + Argon2id.
• Frontend SPA sur le même domaine: session cookie, protection CSRF, pas de logique improvisée côté client.
• API consommée par plusieurs clients: jetons courts, stratégie de rotation, et si besoin un fournisseur d’identité externe.
• Projet d’équipe: variables d’environnement pour les secrets, tests d’intégration dès le départ, et revue des routes sensibles avant le déploiement.

La combinaison la plus durable n’est pas la plus spectaculaire. C’est celle qui garde l’état de connexion simple, les secrets hors du code, les mots de passe correctement hachés et les routes sensibles protégées par des règles que vous pouvez expliquer en une minute. C’est ce niveau de clarté qui fait la différence entre une authentification Flask qui “fonctionne” et une authentification qu’on peut vraiment exploiter en production.