# Sécurisation d'API

## Recommandations

* La [**sécurisation de l'API au niveau applicatif**](#sécurisation-au-niveau-applicatif) est nécessaire, pour identifier le client et agir si besoin (quotas, blocage temporaire...)
* Il convient également de [**sécuriser les échanges au niveau transport**](#sécurisation-au-niveau-transport), quelle que soit la sécurisation choisie au niveau applicatif.
* Si l'objectif est **ZeroTrust**, on recherche la sécurisation forte au niveau applicatif ET au niveau transport. Sinon il faut apprécier la combinaison des mécanismes de sécurité (ex : VPN + SSL + API Key, OAuth + SSL mutuel...)

## Sécurisation au niveau applicatif

Voici différentes manières de sécuriser une API REST au niveau applicatif, du plus sécurisé au moins sécurisé :

| Mécanisme      | Description                                                                                                 | Cas d'usage                                                                                                                                                               | Exemples                                                                                                                                            |
| -------------- | ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| **OAuth2**     | Protocole standard et complet                                                                               | <p>Données particulièrement sensibles.<br>Habilitations de niveau champ.<br>Consentement utilisateur.</p>                                                                 | <p>API partenaire particulièrement sensible.<br>Fournisseur de Données FranceConnect.</p>                                                           |
| **JWT Token**  | <p>Mécanisme de jeton avec authentification préalable.<br>Peut-être utilisé en combinaison avec OAuth2.</p> | <p>Signature numérique.<br>Chiffrement des données.<br>Performance (Stateless).</p>                                                                                       | <p>Exposer une API à un grand nombre de partenaires, avec les mêmes habilitations.<br>Environnement distribué.<br>Routage entre micro-services.</p> |
| **API Key**    | Mécanisme minimum utile et nécessaire                                                                       | <p>Authentification simple de l'application cliente sans gestion de session native (pas d'expiration/rafraichissement de jetons).<br>Communication serveur à serveur.</p> | <p>API privée exposée à d'autres applications internes.<br>Référentiel de données publiques.</p>                                                    |
| **Basic Auth** | Authentification simple par identifiant et mot de passe                                                     | *À proscrire*                                                                                                                                                             | *n/a*                                                                                                                                               |

Quelle que soit la solution, il faut prévoir un mécanisme de **révocation d'accès** pour un client en particulier. Pour une **révocation immédiate**, il est peut-être nécessaire de gérer une session ou blacklist en base de données, au détriment de la performance. Mais une durée de session courte est généralement suffisante.

## Sécurisation au niveau transport

Voici différentes manières de sécuriser une API REST au niveau transport, du plus sécurisé au moins sécurisé :

* **VPN** : plus lourd et moins performant. À réserver au transport de données particulièrement sensibles en contexte Internet.
* **Rupture de protocole** : dès lors que l'API est exposée sur Internet, il faut au moins un intermédiaire de type [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/), [Reverse Proxy](https://fr.wikipedia.org/wiki/Proxy_inverse) ou [API Gateway](/ressources/concevoir/api/api-gateway.md) pour réduire le risque de trafic non sollicité et autres intrusions.
* **Certificats SSL mutuels** (2 Way SSL) : double authentification des parties. Nécessite le paramétrage de certificats SSL de chaque côté, dans un reverse proxy ou une API Gateway.
* **Certificat SSL simple** : déploiement de certificat côté API seulement. Convient pour une API publique ou une API partenaire pas trop sensible.

## Ressources

[Recommandations CNIL](https://www.cnil.fr/fr/api-les-recommandations-de-la-cnil-sur-le-partage-de-donnees)


---

# 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://dnum-ministeres-sociaux.gitbook.io/ressources/concevoir/api/api-securite.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.