chiffrement et hachage

Un **cookie** est un petit fichier stocké dans le navigateur contenant des données utilisées par un site web. Il est envoyé automatiquement au serveur (à chaque requête HTTP).

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.

Il existe plusieurs types de cookies

- **Session Cookie** : Expire à la fermeture du navigateur.

- **Persistent Cookie** : Stocké pour une durée définie.

console.log(document.cookie); //sauf HttpOnly

```

## 3. 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** sont pratiques pour les sessions classiques, mais nécessitent des protections contre les CSRF. En général, on **combine des deux** en utilisant des tokens stockés dans des cookies sécurisés (`HttpOnly`, `Secure`).

## 4. Les différents types de tokens

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.

### 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** sont pratiques pour les sessions classiques, mais nécessitent des protections contre les certaines attaques. En général, on **combine des deux** en utilisant des tokens stockés dans des cookies sécurisés (`HttpOnly`, `Secure`).

**Bonnes pratiques de sécurité** :

Vu que ces chaînes de caractères sont utilisées pour authentifier, il faut :

- Toujours utiliser **HTTPS**.

- Protéger les tokens avec une expiration courte et un refresh token sécurisé.

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

Voici quelques exemples de token que vous rencontrerez dans vos parcours SLAM ou SISR. 

## 4. Les différents types de tokens

### **4.1. API Key (Clé d'API)**

L'**API Key** est une clé unique générée pour identifier et authentifier une application appelant une API.

### **4.1. Access Token (Token d'accès)**

Un **access token** est un jeton temporaire qui permet à une application (client) d'accéder aux ressources protégées d'un utilisateur.

#### **Caractéristiques principales** :

- Fournit un accès basique à des ressources ou services.

- Simple à configurer mais moins sécurisée (pas de gestion avancée des permissions ou expiration automatique).

#### **Exemple** :

Lorsqu'un développeur utilise l'API Google Maps, il doit inclure sa clé API dans les requêtes :

   ```http

   GET https://maps.googleapis.com/maps/api/geocode/json?address=Paris&key=AIzaSyDxxx

   ```

Si la clé est valide, l'API retourne les coordonnées géographiques pour "Paris".

### **4.2. *Access Token* (Token d'accès) et *Bearer Token* (Token porteur)**

Un **access token** est un jeton temporaire qui permet à une application (client) d'accéder aux ressources protégées d'un utilisateur. Un **bearer token**, type courant d'access token, est utilisé pour accorder un accès direct. Celui qui possède ce token peut accéder à la ressource.

#### **Caractéristiques principales** :

- Fourni par un **serveur d'autorisation** après une authentification réussie.

  - Le sujet auquel il se rapporte (par ex. : l'utilisateur).

- Doit être transmis par le client dans les requêtes (souvent dans des en-têtes HTTP).

#### **Exemple** :

#### **Caractéristiques complémentaires du Bearer Token** :

- Inclus dans l'en-tête HTTP `Authorization` lors de l'envoi d'une requête.

- Considéré comme une "clé d'accès" : en cas de compromission, il peut être utilisé par une tierce partie.

#### **Exemple 1** :

1. Lorsqu'une application web veut accéder aux informations utilisateur via l'API Google, elle envoie un access token dans l'en-tête HTTP :

   ```http

   GET /calendar/v3/users/me/calendarList HTTP/1.1

   ```

2. Si le token est valide, Google répond avec la liste des calendriers de l'utilisateur.

#### **Exemple 2** :

1. Une requête REST utilisant un bearer token dans l'en-tête :

   ```http

   GET /api/v2/user/profile HTTP/1.1

   Authorization: Bearer abc123xyz456

   ```

2. Si le token est valide, le serveur renvoie les informations de profil utilisateur.

### **4.2. Refresh Token (Token de rafraîchissement)**

### **4.3. Refresh Token (Token de rafraîchissement)**

Un **refresh token** est utilisé pour obtenir un **nouvel access token** sans nécessiter une nouvelle authentification de l'utilisateur.

#### **Caractéristiques principales** :

- Ne doit jamais être partagé publiquement ou stocké dans des endroits non sécurisés.

#### **Exemple** :

Un utilisateur accède régulièrement à une application mobile, mais l'access token expire après 30 minutes.  

Pour éviter de redemander les identifiants à l'utilisateur, l'application utilise le refresh token pour en obtenir un nouveau en appelant l'endpoint :

Un utilisateur accède régulièrement à une application mobile, mais l'*access token* expire après 30 minutes. Pour éviter de redemander les identifiants à l'utilisateur, l'application utilise le *refresh token* pour en obtenir un nouveau en appelant l'*endpoint* :

   ```http

   POST /oauth2/token HTTP/1.1

   Content-Type: application/x-www-form-urlencoded

   grant_type=refresh_token&refresh_token=1//04vLbX1H...

   ```

Le serveur répond avec un nouvel access token valide.

Le serveur répond avec un nouvel *access token* valide.

### **4.3. ID Token**

Un **ID token** est utilisé pour **identifier un utilisateur**. Il ne donne pas accès à des ressources mais est souvent utilisé pour des mécanismes d'authentification, comme dans OpenID Connect.

### **4.4. ID Token**

Un **ID token** est utilisé pour **identifier un utilisateur**. Il ne donne pas accès à des ressources, mais reste souvent utilisé pour des mécanismes d'authentification, comme dans OpenID Connect.

#### **Caractéristiques principales** :

- Contient des informations sur l'utilisateur, codées généralement sous forme JWT (JSON Web Token).

- **Signature** (troisième partie après le dernier `.`) : `_kC7j_A1Kfw`

### **4.4. Bearer Token (Token porteur)**

Un **bearer token**, type courant d'access token, est utilisé pour accorder un accès direct. Celui qui possède ce token peut accéder à la ressource.

#### **Caractéristiques principales** :

- Inclus dans l'en-tête HTTP `Authorization` lors de l'envoi d'une requête.

- Considéré comme une "clé d'accès" : en cas de compromission, il peut être utilisé par une tierce partie.

#### **Exemple** :

Une requête REST utilisant un bearer token dans l'en-tête :

   ```http

   GET /api/v2/user/profile HTTP/1.1

   Authorization: Bearer abc123xyz456

   ```

Si le token est valide, le serveur renvoie les informations de profil utilisateur.

### **4.5. CSRF Token (Token contre les attaques CSRF)**

Un **CSRF token** (Cross-Site Request Forgery token) est généré pour aider à sécuriser les requêtes des utilisateurs contre les attaques CSRF.

   ```

Lorsqu'une attaque tente d'envoyer une requête malveillante sans ce token, la requête est rejetée.

### **4.6. API Key (Clé API)**

L'**API Key** est une clé unique générée pour identifier et authentifier une application appelant une API.

#### **Caractéristiques principales** :

- Fournit un accès basique à des ressources ou services.

- Simple à configurer mais moins sécurisée (pas de gestion avancée des permissions ou expiration automatique).

#### **Exemple** :

Lorsqu'un développeur utilise l'API Google Maps, il doit inclure sa clé API dans les requêtes :

   ```http

   GET https://maps.googleapis.com/maps/api/geocode/json?address=Paris&key=AIzaSyDxxx

   ```

Si la clé est valide, l'API retourne les coordonnées géographiques pour "Paris".

## 5. **Stockage des tokens coté client**

Le stockage des tokens côté client représente un défi important pour équilibrer **sécurité** et **utilisabilité**. Les tokens sont utilisés pour authentifier ou autoriser un utilisateur, et doivent donc être protégés contre les attaques courantes, comme le **Cross-Site Scripting (XSS)** ou le **Cross-Site Request Forgery (CSRF)**. Voici les principales options disponibles pour stocker des tokens sur le client, avec leurs avantages et inconvénients.