Comment sécuriser une API REST (authentification, autorisation, transport) ?

Question

IT Interview Practice · Accepted Answer

Sécuriser une API REST signifie répondre à trois questions à chaque requête : **qui êtes-vous** (authentication), **qu'avez-vous le droit de faire** (authorization), et **le canal est-il privé** (transport). Comme REST est **stateless**, les credentials doivent voyager avec chaque requête plutôt que de résider dans une session serveur.

## Transport : toujours HTTPS

Tout ce qui suit suppose du **TLS/HTTPS**. Sans cela, les tokens et les API keys voyagent en clair et peuvent être interceptés (sniffed). C'est non négociable — un bearer token sur HTTP est un token divulgué.

## Options d'authentification

**API keys** — un secret statique dans un header. Simple ; bon pour du server-to-server et pour identifier une *application*, pas un utilisateur. Faibles à elles seules (pas d'expiration, pas de scope) sauf si associées à d'autres mesures.
```http
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
```

**OAuth 2.0** — le standard pour l'accès **délégué** (« laisser l'App X lire mes données sans mon mot de passe »). L'app obtient un **access token** via un flow (p. ex. Authorization Code) et l'envoie comme bearer token. C'est ainsi que fonctionnent « Sign in with Google » et les intégrations tierces.

**JWT (JSON Web Token)** — un *format* courant de token : un token signé et autonome portant des claims (user id, roles, expiration). Le serveur vérifie la signature — aucune recherche en base nécessaire, ce qui convient au REST stateless.
```text
header.payload.signature   (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
```

## Authorization : scopes et roles

L'authentication prouve l'identité ; l'**authorization** décide de l'accès. Les tokens portent des **scopes** (`orders:read`, `orders:write`) ou des rôles ; le serveur les vérifie par endpoint et retourne `403 Forbidden` quand ils sont insuffisants (vs `401` pour une auth absente/invalide).

```text
Token absent/invalide      → 401 Unauthorized
Token valide, sans scope   → 403 Forbidden
```

## Autres éléments essentiels

```text
✓ Access tokens à courte durée de vie + refresh tokens (limitent le rayon d'impact en cas de fuite)
✓ Rate limiting (429) pour émousser le brute-force et les abus
✓ Valider/assainir toutes les entrées ; ne jamais faire confiance au client
✓ Principe du moindre privilège sur les scopes
```

## Pourquoi c'est important

La sécurité est là où une petite erreur devient une brèche, donc les recruteurs s'en servent pour voir si vous raisonnez de façon structurelle plutôt que de réciter des buzzwords. Le signal qu'ils recherchent est que vous **séparez les trois couches** — transport (HTTPS, toujours), authentication (prouver l'identité, sans état, via bearer tokens/JWT/OAuth), et authorization (scopes et moindre privilège) — et que vous ne les confondez pas, p. ex. en utilisant correctement `401` pour « non authentifié » versus `403` pour « authentifié mais non autorisé ». Les bonnes réponses montrent une conscience des compromis pratiques : les JWT sont pratiques et sans état mais difficiles à révoquer avant leur expiration (d'où des durées de vie courtes plus des refresh tokens), les API keys identifient des apps et non des users, et OAuth existe précisément pour que les utilisateurs ne remettent pas leur mot de passe à des tiers. Le relier au statelessness de REST — des credentials à chaque requête, pas de session serveur — montre que vous comprenez *pourquoi* la sécurité des API a la forme qu'elle a.

Transport : toujours HTTPS

Options d'authentification

Authorization : scopes et roles

Autres éléments essentiels

Pourquoi c'est important

Questions connexes