Un **token** est une chaîne de caractères utilisée pour l'authentification et l'autorisation dans les applications web et API.
En fonction des besoins (authentification, protection des formulaires, API sécurisées...), différents tokens peuvent être combinés pour renforcer la sécurité d’une application.
### Tokens et lois (RGPD)
Les tokens comme les JWT ont été créés pour répondre à plusieurs besoins techniques :
-**Authentification sans état :** Les serveurs n’ont pas besoin de sauvegarder l’état utilisateur, les informations nécessaires sont incluses dans le token.
-**Interopérabilité :** Les tokens peuvent être échangés entre différents systèmes ou parties d’un système distribué.
-**Sécurité :** Une signature permet de vérifier l’intégrité des données du token et s’assurer qu'elles n’ont pas été altérées.
-**Flexibilité :** Maintenus légers, les tokens fonctionnent sur une variété de protocoles (HTTP, websockets, etc.), contrairement aux sessions basées sur des cookies.
- Le **RGPD (Règlement Général sur la Protection des Données)** et les lois relatives au traçage des cookies visent à protéger la vie privée des utilisateurs. Ces réglementations concernent la collecte, le stockage et l'utilisation des données personnelles, en particulier pour des finalités publicitaires.
Les **tokens** ne remplacent ni ne suppriment l’utilisation des cookies :
- Ils peuvent être **utilisés conjointement avec les cookies** (par exemple, un JWT peut être stocké dans un *cookie* ou dans le stockage local du navigateur).
- Cependant, si un **JWT contient des données personnelles identifiables**, son utilisation doit respecter le RGPD, notamment en ce qui concerne la sécurité, la durée de conservation, et la nécessité du consentement utilisateur.
### Types de tokens
Il existe plusieurs types de tokens, chacun ayant une utilisation spécifique.
Dans un **JWT (JSON Web Token)**, le token est constitué de trois parties distinctes, séparées par des points (`.`) :
1.**Header** : Première partie avant le premier point.
2.**Payload** : Deuxième partie entre le premier et le deuxième point.
3.**Signature** : Troisième partie après le deuxième point.
-**Header** (première partie jusqu'au premier `.`) : `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9`
-**Payload** (deuxième partie entre les deux `.`) : `eyJ1c2VybmFtZSI6ImpvaG4iLCJleHAiOjE2NzAwMjYyMDB9`
-**Signature** (troisième partie après le dernier `.`) : `_kC7j_A1Kfw`
- Les **OAuth Access Tokens** sont des jetons d’accès utilisés dans le cadre du protocole OAuth 2.0, qui permet l’authentification et l’autorisation d’accès aux ressources d’un utilisateur sans exposer ses identifiants. Ces tokens sont généralement envoyés dans l’en-tête HTTP `Authorization: Bearer <token>`, comme dans cet exemple :
```javascript
fetch('https://api.example.com/protected',{
method:'GET',
headers:{
'Authorization':'Bearer <your_access_token>'
}
})
.then(response=>response.json())
.then(data=>console.log(data));
```
Ils expirent généralement après une courte durée et nécessitent un **Refresh Token** pour renouveler l'accès sans forcer l'utilisateur à se reconnecter.
Le **Refresh Token** est un token spécial permettant d'obtenir un nouveau token d'accès sans nécessiter une ré-authentification complète. Contrairement aux tokens d'accès, il est conçu pour être stocké de manière sécurisée, comme dans un cookie HttpOnly ou une base de données.
Les **CSRF Tokens (Cross-Site Request Forgery Tokens)** sont utilisés pour protéger les applications web contre les attaques CSRF, qui exploitent la confiance d’un site web envers un utilisateur authentifié. Un token CSRF est généré côté serveur et inséré dans un champ caché d’un formulaire. Lorsque l’utilisateur soumet le formulaire, le serveur vérifie la validité du token avant de traiter la requête. Voici un exemple d’implémentation :
Ce mécanisme empêche les attaques où un utilisateur connecté pourrait être forcé à exécuter une action malveillante à son insu.
Les **API Tokens** sont des clés secrètes utilisées pour sécuriser l'accès aux API. Contrairement aux tokens OAuth, ils ne sont pas toujours liés à un utilisateur spécifique mais plutôt à une application ou un service. Ils permettent d’authentifier les requêtes sans nécessiter une session utilisateur. Un exemple d'utilisation serait l'ajout d’un token dans une requête API :
```javascript
fetch('https://api.example.com/data',{
method:'GET',
headers:{
'Authorization':'Token abcdef123456'
}
})
.then(response=>response.json())
.then(data=>console.log(data));
```
Ces tokens doivent être stockés de manière sécurisée et régénérés régulièrement pour éviter tout risque de compromission.
## 2. Qu'est-ce qu'un Cookie ?
Un **cookie** est un petit fichier stocké dans le navigateur contenant des données utilisées par un site web.
### Types de cookies
-**Session Cookie** : Expire à la fermeture du navigateur.
-**Persistent Cookie** : Stocké pour une durée définie.
-**Secure Cookie** : Accessible uniquement via HTTPS.
-**HttpOnly Cookie** : Non accessible par JavaScript (protège contre les attaques XSS).
### Fonctionnement
1. Le serveur envoie un cookie au client via l'en-tête `Set-Cookie`.
2. Le navigateur stocke le cookie.
3. À chaque requête suivante, le navigateur renvoie automatiquement le cookie au serveur.
4. Le serveur utilise les informations du cookie pour identifier l'utilisateur.
### Exemples d'utilisation
#### 1. Stockage d'un jeton de session dans un cookie
| Transmission | Manuel (`Authorization` header) | Automatique (`Set-Cookie`) |
| Sécurité | Peut être intercepté si mal protégé | Vulnérable aux attaques CSRF |
| Expiration | Défini par l'émetteur | Dépend de la configuration |
| Utilisation | API REST, Single Page Apps, Protection CSRF | Sessions classiques |
| Dépendance au serveur | Stateless | Stateful |
---
## 4. Faut-il choisir un cookie ou un token ?!
Les **Tokens** sont recommandés pour les applications modernes (Single Page Apps, API REST, microservices). Les **Cookies** : Pratiques pour les sessions classiques, mais nécessitent des protections contre CSRF.
-**Combinaison des deux** : Utiliser des tokens stockés dans des cookies sécurisés (`HttpOnly`, `Secure`).
🔹 **Bonnes pratiques de sécurité** :
- Toujours utiliser **HTTPS**.
- Protéger les tokens avec une expiration courte et un refresh token sécurisé.
- Utiliser `HttpOnly` et `Secure` pour les cookies.
- Implémenter des mécanismes de protection contre XSS et CSRF.
💡 **Exemple d'utilisation** :
- Un site web avec un back-end peut stocker un **token JWT dans un cookie HttpOnly** pour sécuriser les sessions tout en utilisant les avantages des tokens.
