0Pricing
Cyber Security Academy · Leçon

Flux OAuth 2.0

Autorisations accordées et jetons.

Flux OAuth 2.0 est une leçon Cyber Security Academy gratuite sur CoddyKit. Ceci est la leçon 1 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Cyber Security Academy, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Cyber Security Academy comprend 4 leçons au total.

Ce que résout réellement OAuth 2.0

OAuth 2.0 est un cadre d'autorisation déléguée. Il permet à un utilisateur d'accorder à une application tierce un accès limité à ses ressources sur un autre service sans partager son mot de passe.

  • Il s'agit d'autorisation (ce qu'une application peut faire), et non d'authentification (l'identité de l'utilisateur).
  • L'application reçoit un access_token limité à une portée, jamais les identifiants de l'utilisateur.

Les défenseurs doivent se rappeler qu'OAuth seul ne prouve pas l'identité. Considérer un jeton d'accès comme une preuve de connexion est une erreur classique à laquelle OIDC répond.

Les quatre rôles

Chaque flux OAuth fait intervenir quatre rôles. Les représenter correctement est essentiel pour modéliser les menaces.

  • Propriétaire des ressources : l'utilisateur qui possède les données.
  • Client : l'application qui demande l'accès.
  • Serveur d'autorisation (AS) : émet les jetons après le consentement.
  • Serveur de ressources (RS) : l'API qui contient les données protégées et valide les jetons.

Des limites de confiance séparent ces rôles. Un client compromis ou un AS trop permissif compromet toute la chaîne.

Roles:
  Resource Owner  -> grants consent
  Client          -> requests + uses tokens
  Authorization Server -> issues tokens
  Resource Server -> validates tokens

Flux du code d'autorisation

Le flux du code d'autorisation est recommandé pour les applications Web et mobiles. Il sépare la redirection visible par l'utilisateur de l'échange secret des jetons.

  • L'utilisateur est redirigé vers l'AS pour s'authentifier et donner son consentement.
  • L'AS renvoie un code à courte durée de vie à l'URI de redirection enregistrée.
  • Le client échange le code côté serveur contre des jetons via un canal serveur à serveur.

Comme les jetons sont obtenus via ce canal serveur à serveur, ils n'apparaissent jamais dans la barre d'adresse ni dans l'historique du navigateur.

GET /authorize?response_type=code
  &client_id=app123
  &redirect_uri=https://app.example/cb
  &scope=read:profile
  &state=xyz

// then back-channel:
POST /token  grant_type=authorization_code&code=...

PKCE : preuve de possession de la clé pour l'échange de code

PKCE (RFC 7636) renforce le flux du code d'autorisation et est désormais recommandé pour tous les clients, y compris les clients confidentiels.

  • Le client génère un code_verifier aléatoire et envoie son hachage sous la forme d'un code_challenge.
  • Lors de l'échange des jetons, il doit présenter le vérificateur d'origine.

Cela associe le code au demandeur d'origine et empêche un attaquant qui intercepterait le code d'autorisation de l'échanger contre des jetons.

code_verifier  = random 43-128 chars
code_challenge = BASE64URL(SHA256(verifier))

/authorize ... &code_challenge=...&code_challenge_method=S256
/token     ... &code_verifier=<original>

Flux d'identifiants client

Le flux d'identifiants client est destiné aux accès de machine à machine, lorsqu'aucun utilisateur n'intervient (un service principal qui appelle une API).

  • Le client s'authentifie avec ses propres identifiants et reçoit un jeton d'accès.
  • Il n'y a généralement ni consentement de l'utilisateur ni jeton d'actualisation.

Limitez strictement la portée de ces jetons et faites régulièrement tourner les secrets du client. N'utilisez jamais ce flux pour usurper l'identité d'utilisateurs finaux.

POST /token
  grant_type=client_credentials
  client_id=service-a
  client_secret=***
  scope=orders:read

Jetons d'accès ou jetons d'actualisation

OAuth émet deux principaux types de jetons, dont les durées de vie et les règles de gestion sont très différentes.

  • Jeton d'accès : à courte durée de vie, il est envoyé au serveur de ressources lors de chaque appel. Considérez-le comme un justificatif au porteur.
  • Jeton d'actualisation : à longue durée de vie, il est utilisé uniquement auprès de l'AS pour obtenir de nouveaux jetons d'accès.

Les jetons d'actualisation ont une grande valeur. Stockez-les de manière sécurisée, associez-les au client et prenez en charge leur révocation.

POST /token
  grant_type=refresh_token
  refresh_token=<long-lived>
  client_id=app123

Jetons porteurs et transport

La plupart des jetons d’accès OAuth sont des jetons porteurs : quiconque détient le jeton peut l’utiliser, comme de l’argent liquide.

  • Transmettez-les toujours via TLS ; jamais dans des URL, où ils peuvent apparaître dans les journaux et les référents.
  • Envoyez-les via l’en-tête Authorization.
  • Envisagez des jetons liés à l’émetteur (DPoP, mTLS) pour les API à haut risque.
Authorization: Bearer eyJhbGciOiJSUzI1NiIs...

// AVOID:
GET /api/data?access_token=...   // leaks in logs

Le flux implicite est obsolète

L’ancien flux implicite renvoyait directement les jetons dans le fragment de l’URI de redirection. Il est désormais déconseillé par le BCP de sécurité d’OAuth 2.0 et supprimé dans OAuth 2.1.

  • Les jetons fuyaient par l’historique du navigateur, les en-têtes de référent et les journaux.
  • L’absence de canal secondaire entraînait une authentification plus faible du client.

Utilisez plutôt le code d’autorisation avec PKCE pour les SPA.

Le paramètre state et le CSRF

Le paramètre state protège l’étape de redirection contre le CSRF. Le client génère une valeur aléatoire, la stocke dans la session et la vérifie lors du rappel.

  • Si le state renvoyé ne correspond pas, rejetez la réponse.
  • Cela empêche un attaquant d’injecter son propre code d’autorisation dans la session d’une victime.
before:  session.state = randomNonce()
/authorize ... &state=<nonce>

on callback:
  if (req.state !== session.state) reject()

Portées et moindre privilège

Les portées expriment le niveau de détail des accès accordés par un jeton. Appliquez le principe du moindre privilège à chaque étape.

  • Demandez uniquement les portées nécessaires à la fonctionnalité (read:profile, et non admin).
  • Les serveurs de ressources doivent appliquer la portée à chaque point de terminaison, et pas seulement faire confiance à un jeton valide.

Un consentement trop large constitue un risque courant dans le monde réel : les utilisateurs approuvent des applications qui demandent bien plus que nécessaire.

Erreurs courantes de configuration OAuth

La plupart des incidents OAuth proviennent de la configuration, et non du protocole lui-même.

  • Une redirection ouverte / correspondance laxiste de redirect_uri permet aux attaquants de voler des codes.
  • L’absence de state ou de PKCE permet le CSRF et l’injection de codes.
  • Des jetons d’accès à longue durée de vie sans possibilité de révocation.
  • Considérer un jeton d’accès comme une assertion d’authentification.

Enregistrez des URI de redirection exactes et validez-les strictement.

redirect_uri allowlist:
  EXACT: https://app.example/cb
  NOT:   https://app.example/*  (too broad)

Vérification rapide : sécuriser l’authentification d’une SPA

Choisissez le flux moderne approprié pour le scénario ci-dessous.

Récapitulatif : flux OAuth 2.0

Points essentiels :

  • OAuth 2.0 fournit une autorisation déléguée, et non une authentification.
  • Quatre rôles : propriétaire de la ressource, client, serveur d’autorisation et serveur de ressources.
  • Le code d’autorisation + PKCE est le choix par défaut pour le Web, les appareils mobiles et les SPA.
  • Les informations d’identification du client couvrent les accès de machine à machine.
  • Protégez-les avec state, une correspondance stricte des URI de redirection, des jetons d’accès à courte durée de vie et TLS partout.
  • Les flux implicite et par mot de passe sont obsolètes.

Questions Fréquemment Posées

La leçon « Flux OAuth 2.0 » est-elle gratuite ?

Oui — le texte complet de « Flux OAuth 2.0 » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Cyber Security Academy, passe à CoddyKit PRO. Le cours Cyber Security Academy comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Flux OAuth 2.0 » ?

Autorisations accordées et jetons. Tu pratiques Cyber Security Academy avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer Cyber Security Academy ?

Aucune expérience préalable n'est requise. Cyber Security Academy sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 1 sur 4.

Combien de temps prend la leçon « Flux OAuth 2.0 » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon Cyber Security Academy ?

Oui. Chaque leçon Cyber Security Academy inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

  1. Flux OAuth 2.0
  2. OpenID Connect (OIDC)
  3. SAML et fédération
  4. Attaques contre les jetons et renforcement
← Retour à Cyber Security Academy