# Authentification et Session Management

## **De quoi avons-nous besoin ?**

### **Session management ?**

Nope ! **L’API ReST doit être Stateless !**

Si des informations liées à la session doivent être maintenues, celles-ci doivent être gérées par le client.

Les données persistées par l’API ReST sont associées à des ressources.

Rien n’interdit l’expiration d’une ressource : `GET /carts/1234 => 404 Not Found`

{% hint style="warning" %}
Ne schtroumpfez pas !`SMURF /smurf-api/sessions/current`
{% endhint %}

### **Authentification**

Idéalement, il nous faudrait un mécanisme d’authentification même si les données de l’API sont publiques.

### **Identification**

L'identification n'est implémentée que si réellement nécessaire.

**L’authentification et l’identification sont des notions distinctes.**\
Il est possible d’authentifier un utilisateur sans l’identifier.\
Il est également possible d’identifier un utilisateur sans l’authentifier mais nous n’aurions aucune garantie de l’identité.

### **Logout et révocation**

Le *logout* peut provenir d’une autre source que l’utilisateur final.

{% hint style="danger" %}
Les "tokens" d’authentification **ne doivent pas être transmis dans l’URL.**\
`GET /users/123?token=asdf....`

L’authentification "basic-auth" ne doit pas être utilisée.

Les *tokens* doivent être transmis dans le *header* `Authorization`

`Authorization: Bearer xxxxxx, Extra yyyyy`
{% endhint %}

## **Mécanismes d’authentification**

Nous parcourerons plus tard les différents mécanismes d’authentification envisageables.

Globalement *(modulo quelques étapes)*, la plupart des mécanismes d’authentification fonctionnent ainsi :

1. Le service d’authentification fournit un *token* unique au client.
2. Le client transmet ce *token* aux APIs ReST du fournisseur de service.
3. Le fournisseur de service déduit les autorisations d’accès en fonction de ce *token*.

## **Session Management côté client**

Le cas le plus complexe est celui où le client est un *browser*.

Si vous souhaitez persister des données dans le *browser* afin que l’utilisateur puisse retrouver le même contexte en changeant de fenêtre ou après un *refresh* :

* Evitez absolument l’utilisation des *cookies* ne serait-ce que pour les raisons suivantes :
  * Ce n’est pas leur rôle.
  * Vous ne voulez pas envoyer toutes ces données au backend à chaque requête.
  * Cookies are EVIL !<br>

* **`IndexedDB`** et **`localStorage`** sont là pour ça.<br>

* Problème 😱

  * L'**`IndexedDB`** et le **`localStorage`** n’ont pas de notion d’expiration sauf sur Firefox :  <https://developer.mozilla.org/en-US/docs/Web/API/IDBFactory/open>.
  * Jetez un coup d’oeil au contenu de vos storages après *logout* ou fermeture du *browser*, vous serez surpris de découvrir ce qu’on y retrouve.

* Secure Storage
  * en attendant une solution *in-the-browser*, il est recommandé de chiffrer les données stockées localement avec **une clé temporaire et unique pour chaque client transmise par l’API ReST,**
  * <https://github.com/jas-/crypt.io>,
  * ou encore mieux, en stockant la clé via l'API browser `webauthn` quand celle-ci sera globalement disponible. <https://developers.google.com/web/updates/2018/05/webauthn>&#x20;


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://guide-api-rest.marmicode.fr/securite-des-apis-rest/authentification-et-session-management.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.