Retour aux articles

Sécuriser ses APIs REST avec OAuth2 et OIDC

Pour sécuriser durablement vos APIs REST, il ne suffit plus de « mettre un bearer token ». Les bonnes pratiques 2025–2026 imposent une gestion fine des tokens, des scopes et des audiences, alignée sur OAuth 2.1 et OIDC.

Publié le 16 avril 2026

Les enjeux actuels de sécurité pour les APIs REST

Les APIs REST sont devenues le cœur des architectures modernes : microservices, frontends JavaScript, applications mobiles, intégrations partenaires. Cette centralité en fait une cible privilégiée pour les attaques, notamment via des implémentations OAuth2 approximatives.

Les incidents récents montrent que la plupart des failles ne viennent pas du protocole, mais de décisions techniques discutables : tokens trop longs, scopes trop larges, absence de révocation, confusion entre authentification et autorisation.

Access Token vs ID Token : ne plus les confondre

Dans un schéma moderne, l’ID Token (OIDC) sert à identifier l’utilisateur côté client, tandis que l’Access Token sert uniquement à appeler les APIs. Mélanger ces rôles conduit à exposer des données sensibles ou à accorder des accès non prévus.

Les APIs REST doivent considérer l’Access Token comme un jeton d’autorisation ciblé : audience correcte, scopes adaptés, durée de vie courte. L’ID Token ne devrait jamais être utilisé comme « passe-partout » pour accéder aux ressources.

Conception des scopes et permissions API

Le principe du moindre privilège doit guider la conception des scopes : chaque scope doit correspondre à un ensemble limité d’actions (lecture, écriture, administration d’un périmètre précis). Les scopes génériques « full_access » ou « admin_global » ouvrent la porte à des escalades de privilèges massives.

Dans les environnements microservices, il est pertinent de segmenter les scopes par service ou domaine fonctionnel, et de s’assurer que chaque API ne consomme que les scopes qui la concernent. Les contrôles d’accès doivent être systématiquement appliqués côté API, même si le frontend semble « bien se comporter ».

Durées de vie et rotation des tokens

Pour limiter l’impact d’un token compromis, les Access Tokens doivent avoir une durée de vie courte, tandis que les Refresh Tokens, plus longs, doivent être protégés par des mécanismes de rotation et de détection de réutilisation. En cas de suspicion de fuite, la révocation de la « famille » de tokens permet de couper rapidement l’accès.

Les APIs doivent être prêtes à gérer la révocation : vérifier la validité des tokens (introspection ou validation locale avec listes de révocation), et réagir correctement aux erreurs d’authentification pour éviter les boucles infinies de rafraîchissement côté client.

Stockage sécurisé des tokens côté client

Côté web, les Refresh Tokens ne devraient pas être exposés au JavaScript du navigateur. L’usage de cookies HttpOnly, Secure et SameSite, combiné à un backend-for-frontend, permet de garder les tokens sensibles côté serveur tout en offrant une expérience utilisateur fluide.

Côté mobile, les tokens doivent être stockés dans les mécanismes sécurisés du système (Keychain, Keystore, etc.), jamais en clair dans des préférences non chiffrées ou des fichiers temporaires. Ces choix réduisent considérablement le risque en cas de device compromis ou d’application malveillante.

Patterns d’architecture : BFF, audience et séparation des responsabilités

Le pattern BFF (backend-for-frontend) est de plus en plus recommandé pour les frontends riches : le BFF gère les échanges OAuth2/OIDC, stocke les tokens, expose au navigateur uniquement des cookies de session et appelle les APIs au nom de l’utilisateur.

Par ailleurs, la séparation nette entre fournisseur d’identité, clients et APIs est essentielle : chaque composant a un rôle précis, et les audiences des tokens doivent refléter cette séparation. Une API ne devrait accepter que des tokens explicitement émis pour elle.

Monter en compétence sur OAuth2/OIDC côté API

Pour les équipes backend, maîtriser ces concepts est devenu aussi important que savoir concevoir un modèle de données. Sans cette maîtrise, les contrôles d’accès restent fragiles, et les migrations vers OAuth 2.1 se transforment en projets à risque.

Une montée en compétence ciblée, via une formation pratique sur OAuth2 et OpenID Connect, permet d’aligner rapidement les développeurs backend et les tech leads sur les bonnes pratiques de sécurisation des APIs REST, des tokens et des scopes.

Sources

  1. OAuth 2.1 Authorization Framework (Internet-Draft, 2026) — datatracker.ietf.org — 2026-03-??
  2. OAuth 2.1: Modern Authorization Best Practices in 2026 — latestfromtechguy.com — 2026-02-??
  3. OAuth 2.0 Security Best Practices for Developers — maida.kim — 2025-03-??
  4. Recommended authorization flows with OpenID Connect (OIDC) and OAuth 2.x — zitadel.com
  5. OpenID Connect Flows: From Implicit to Authorization Code with PKCE & BFF — dev.to — 2024-??-??
  6. What Is OpenID Connect (OIDC) & What You Need To Know In 2025 — stealthkits.net — 2025-??-??
  7. Refresh Token Security: Best Practices for OAuth Token Protection — obsidiansecurity.com — 2026-02-??
  8. Best Practices for OAuth2 in Microservices — securecodecards.com — 2026-03-??

Découvrir le Spark lié : Formation OAuth2 / OIDC pour développeurs