Qu'est-ce que l'authentification ?
Vérifier que quelqu'un est bien qui il prétend être
Vérifier que quelqu'un est bien qui il prétend être
Décider ce qu'une identité déjà vérifiée a le droit de faire
Ce que je sais, ce que je possède, ce que je suis
Jamais en clair ni chiffré : haché avec un algorithme lent et salé (bcrypt, scrypt, Argon2)
Le serveur stocke l'état de connexion et donne au navigateur un identifiant de session dans un cookie
Interdit à JavaScript de lire le cookie : une faille XSS ne peut plus le voler
Un site malveillant fait émettre par ton navigateur une requête vers un site où tu es connecté·e
Un jeton en trois parties encodées base64url, header.payload.signature, dont la signature garantit l'intégrité
Non : le payload est seulement encodé en base64, n'importe qui peut le lire
Le sujet : l'identifiant de l'utilisateur (ou de la machine) que le jeton représente
La date d'expiration, en secondes depuis le 1er janvier 1970 (epoch Unix)
Pour refuser un jeton valide émis pour un autre service
HMAC-SHA256 avec un secret partagé : qui vérifie peut aussi signer
RSA : la clé privée signe, la clé publique vérifie
Forger un jeton dont le header déclare alg none, sans signature, qu'une bibliothèque naïve accepte
On ne peut pas vraiment : d'où des jetons courts (minutes) et une blocklist ou un refresh token
Un jeton longue durée qui sert uniquement à obtenir un nouvel access token, sans refaire le login
Cookie HttpOnly de préférence : localStorage est lisible par tout script, donc volable par XSS
Dans l'en-tête Authorization: Bearer
Un cadre d'autorisation déléguée : une app obtient un accès limité au nom d'un utilisateur
Le serveur qui authentifie l'utilisateur, recueille son consentement et émet les tokens
L'API qui héberge les données protégées et accepte les access tokens
L'application qui demande l'accès, identifiée par un client_id
Une permission demandée par le client et affichée à l'utilisateur au consentement
1. Le client redirige le navigateur vers `/authorize` (clientid, redirecturi, scope, state) 2. L'utilisateur s'authentifie et consent chez l'authorization server 3. Redirection vers `redirect_uri` avec un code à usage unique 4. Le client échange ce code contre des tokens sur `/token`, par un appel serveur à serveur 5. Le client appelle l'API avec l'access token
Prouver que celui qui échange le code est celui qui l'a demandé
Le token arrive dans l'URL du navigateur (fragment), exposé à l'historique, aux scripts et aux extensions
Client Credentials : le client s'authentifie avec son clientid et clientsecret et reçoit un token
Sinon un attaquant fait envoyer le code (ou le token) vers son propre site
À lier la réponse à la requête initiale : protection CSRF du flow
Une couche d'identité au-dessus d'OAuth 2.0 : elle ajoute l'authentification et l'ID token
Un JWT destiné au client, qui atteste l'identité de l'utilisateur authentifié
Non : son audience est le client, pas l'API, et il ne porte pas de scopes
openid
À récupérer les informations de profil de l'utilisateur avec l'access token
Le JSON à /.well-known/openid-configuration qui liste les endpoints, algorithmes et clés du fournisseur
Le jeu de clés publiques du fournisseur, publié en JSON à l'URL jwks_uri, pour vérifier les signatures
À lier l'ID token à la session du client : protection contre le rejeu d'un ID token
Une seule authentification qui ouvre l'accès à plusieurs applications
Le service qui détient les comptes et authentifie les utilisateurs pour le compte des applications
Un protocole de SSO basé sur XML : l'IdP envoie à l'application une assertion signée qui décrit l'utilisateur
Faire confiance à l'IdP d'une autre organisation pour authentifier ses utilisateurs
Un secret statique qui identifie une application appelante, sans représenter un utilisateur
Role-Based Access Control : les permissions vont aux rôles, les utilisateurs reçoivent des rôles
Une paire de clés par site, stockée sur l'appareil : le site garde la publique, la privée signe un défi
Un code à 6 chiffres calculé depuis un secret partagé et l'heure courante, renouvelé toutes les 30 secondes
En appelant l'endpoint d'introspection de l'authorization server
Il limite l'envoi du cookie dans les requêtes qui viennent d'un autre site : protection CSRF
Chaque usage du refresh token en émet un nouveau et invalide l'ancien
401 : pas (ou mal) authentifié. 403 : authentifié, mais pas autorisé
Pour n'accepter que les jetons des émetteurs attendus, même si la signature est valide