Quel mécanisme d'auth pour quel problème ?
Une antisèche pour décider vite. Le critère n'est pas le mécanisme le plus sécurisé sur le papier, mais qui porte l'identité : ton serveur, un jeton auto-porté, un tiers de confiance, ou juste un secret machine.
Pars d'une session cookie côté serveur pour une appli monolithique classique. Passe au JWT si plusieurs services doivent vérifier le token sans appeler une base. OAuth2/OIDC dès qu'un tiers (Google, GitHub) doit authentifier l'utilisateur.
Session cookie / état côté serveur
Le défaut. Simple, révocable immédiatement.
Choisir si : appli monolithique classique, besoin de révoquer une session à tout moment, pas de client mobile/tiers séparé.
Éviter si : architecture multi-services sans store de session partagé, API consommée par des clients variés.
JWT / jeton auto-porté
Le serveur n'a rien à vérifier en base.
Choisir si : microservices, vérification stateless du jeton, mobile/SPA découplés du backend.
Éviter si : besoin de révocation immédiate — un JWT volé reste valide jusqu'à expiration.
OAuth2 / OIDC / délégation d'identité
Se connecter avec un tiers de confiance.
Choisir si : authentification via Google/GitHub/etc., déléguer des accès sans partager de mot de passe, SSO.
Éviter si : appli interne simple sans besoin de délégation — complexité de flux non justifiée.
SAML / SSO entreprise
Le SSO historique du monde entreprise.
Choisir si : intégration avec un IdP d'entreprise existant (Okta, Azure AD), contexte B2B avec exigences legacy.
Éviter si : nouveau projet sans contrainte entreprise — OIDC est plus simple et plus moderne.
Clé API / identification simple
Un secret, pas une identité.
Choisir si : API machine-à-machine, intégrations simples, pas besoin de représenter un utilisateur humain.
Éviter si : authentifier un utilisateur humain avec des permissions fines — pas de session ni de scopes riches.