←

Dev back-end

Authentification et Autorisation

Objectifs

  • Authentifier une personne
  • Limiter des services aux utilisateurs autorisés
  • Maintenir et sécuriser une session
  • Gérer les autorisations

Identité, Authentification, Autorisation

Article: Différences entre identification, autorisation et authentification

Sessions

  • 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

Sessions > Cookies

Navigateur Server requête http réponse avec cookie Sécurisation du cookie par la navigateur. requête http + cookie attaché automatiquement
  • 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.

Sessions > Filesystem

  • 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)

Sessions > entrepôt de données de session (session store)

  • 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.

Sécuriser un mot de passe

https://questionsecu.fr/hachez-salez-poivrez/
  1. Hasher (bcrypt)
    • pour empêcher le vol de mot de passe clair
  2. Saler individuellement avec une valeur associée à chaque utilisateur
    • pour empêcher le bruteforce précalculé
  3. Poivrer avec une valeur secrète globale
    • pour donner du fil à retordre au pirate

SSL / HTTPS

Le concept

http://sebsauvage.net/comprendre/ssl/

Obtenir un certificat

https://letsencrypt.org/fr/

JWT et Jetons

Principe du jeton aléatoire

  • 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

https://blog.ippon.fr/2017/10/12/preuve-dauthentification-avec-jwt/

Compromis par rapport au jeton (token) aléatoire

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

Architectures

architecture n-tiers

https://web2.cegepat.qc.ca/~claudeboutet/index.php/2016/04/14/le-pattern-architectural-n-tiers/ https://www.supinfo.com/articles/single/6437-fonctionnement-une-architecture-trois-tiers
  • + 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)

Microservices

https://www.supinfo.com/articles/single/5676-qu-est-ce-que-architecture-microservices
  • + 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)

autres sources