Dev back-end

Authentification et Autorisation

Les sessions permettent de reconnaitre un même utilisateur au niveau du serveur afin de persister des informations lors de sa navigation.
- On pourra stocker en session des informations comme le niveau de droits (visiteur, authentifié, administrateur) ou l'identité de l'utilisateur.
Faire persister la session présente des enjeux techniques: pour un même site ou service en ligne, il n'est pas garanti que le même serveur réponde systématiquement à la requête.
- Les serveurs pourront en effet être dupliqués derrière un load balancer pour répartir la charge lors de forts trafics.
Caractéristiques d'une session :
- Possède un id unique par visiteur et par navigateur
- Cet id est connu du serveur, et éventuellement du client
- Une session persiste jusqu'à ce que le client ou le serveur décide de l'interrompre
- Optimal: Une session persiste aux redémarrages serveur et au redémarrage du navigateur

Les cookies sont créés par le serveur et contiennent des informations textuelles
Les cookies sont joints à chaque requête du navigateur automatiquement
Les attributs secure="true" et httpOnly="true"garantissent la sécurisation du cookie lors de sa création côté serveur.
On pourra donner une date d'expiration à un cookie. Cela limite de risque de piratage.

Références

Il est possible de stocker une session sur le système de fichier du serveur.
Ce format est déprécié car il n'est pas garantit qu'un même utilisateur joigne la même machine à chaque requête (situation de load balancing)

Le session store répond à une problématique de performance.
- A mettre en place dès qu'une problème de performance est mesurable, pas avant.
Les outils utilisés seront les même que pour du cache applicatif, mais l'architecture sera légèrement différente.
- Cf. Cache vs. Session Store

Hasher (bcrypt)
- pour empêcher le vol de mot de passe clair
Saler individuellement avec une valeur associée à chaque utilisateur
- pour empêcher le bruteforce précalculé
Poivrer avec une valeur secrète globale
- pour donner du fil à retordre au pirate

https://letsencrypt.org/fr/

Lors d'une authentification, émettre un jeton (chaine de caractère aléatoire, au moins 16 caractères): l'enregistrer en base de données et le mettre en cookie (httpOnly=true,secure=true).
- En base de donnée, associer le jeton à l'utilisateur et éventuellement à des permissions spécifiques et à une date d'expiration.
Lors d'une requête comportant le jeton (lu dans le cookies), vérifier en base sa validité et récupérer les informations associées.
Vous avez accès à l'identité du demandeur et à ses permissions.

	JWT	Token aléatoire
Complexité	Plus complèxe	Plus simple
Base de données (BDD)	Diminue le nombre d'accès en BDD	Accès BDD pour chaque requète authentifiée
Niveau de sécurité	des failles de sécurités connues	fort
Invalidation du token	date d'expiration, nécessite une mécanique supplémentaire pour invalider manuellement	configuration en BDD
taille	variable, assez longue	A la discretion de développeur
Données de sessions	Pas adapté au stockage de données de sessions	Récupération de la session côté serveur

+ flexible (on peut remplacer une couche, les interfaces de chaque couche sont exposées)
+ testable (on peut simuler les autres couches pour tester un couche)
+ multi-système (chaque couche est techniquement autonome)
~ performances (une requêtes doit traverser un certain nombre de couches)
- scalabilité (élasticité) (On ne peut pas forcément multiplier facilement une couche)

+ flexible (on peut remplacer une application, les interfaces de chaque application sont exposées)
+ testable (on peut simuler les autres applications pour tester une application)
+ multi-système (chaque application est techniquement autonome)
+ scalabilité (élasticité) (Les applications sont stateless et peuvent être déployées en plusieurs instances)
+ agilité (des cycles de vie indépendants)
~ performances (dépend de la conception)
- stabilité (cycles de vie différents = risque de version incompatibles)