Les standards de sécurité évoluent pour refléter les enseignements du terrain. OAuth 2.0, publié en 2012, a posé les bases de l’autorisation déléguée moderne et reste aujourd’hui le protocole de référence dans la très grande majorité des architectures IAM. OAuth 2.1 s’inscrit dans cette continuité : il consolide en un document unique les bonnes pratiques accumulées depuis plus d’une décennie, en rendant obligatoires des mécanismes jusqu’ici optionnels et en retirant des flux devenus incompatibles avec les exigences de sécurité actuelles. Pour les organisations qui gèrent des environnements d’authentification complexes, comprendre ces évolutions est essentiel pour anticiper les impacts sur leurs infrastructures et rester alignées avec les standards de l’industrie.
Pourquoi parler d’OAuth 2.1 maintenant ?
OAuth 2.0 est le standard d’autorisation déléguée sur lequel repose une part massive des architectures IAM modernes. Depuis sa publication en 2012 (RFC 6749), il a équipé des millions d’applications — des portails RH aux API métier, des applications mobiles aux plateformes cloud. Mais ce succès a eu un revers : au fil des années, OAuth 2.0 s’est enrichi de correctifs et de bonnes pratiques dispersés dans une douzaine de RFCs annexes, rendant les implémentations complexes et propices aux erreurs.
OAuth 2.1 est la réponse de l’IETF à ce problème. Ce n’est pas un nouveau protocole — c’est une consolidation rigoureuse. Un document unique qui balaie dix ans de retours d’expérience, supprime les flux dangereux, et rend obligatoires les bonnes pratiques jusqu’ici optionnelles. Le draft IETF en est aujourd’hui à sa version 14 (octobre 2025), avec une finalisation attendue prochainement.
Bien qu’encore à l’état de draft, OAuth 2.1 est déjà requis par des normes majeures. Anthropic en a fait la fondation du Model Context Protocol (MCP), qui définit comment les agents IA accèdent de manière sécurisée aux outils et données externes. C’est un signal fort : OAuth 2.1 n’est pas une évolution théorique, c’est une exigence opérationnelle qui émerge dès maintenant.
Ce qui disparaît : deux flux supprimés, une dette de sécurité effacée
L’Implicit Grant Flow — le flux qui exposait vos tokens dans l’URL
Conçu à l’origine pour les Single Page Applications (SPAs) qui ne pouvaient pas gérer d’échange côté serveur, l’Implicit Grant retournait directement le token d’accès dans le fragment d’URL (exemple.com#access_token=xyz). Ce token pouvait se retrouver dans l’historique du navigateur, les headers Referer ou les logs de proxy. OAuth 2.1 le supprime définitivement. Les SPAs doivent désormais utiliser le Authorization Code Flow avec PKCE.
Le Resource Owner Password Credentials (ROPC) — la collecte de mots de passe déguisée
Ce flux permettait à une application de collecter directement login et mot de passe pour les transmettre à l’Authorization Server — une pratique qui contredisait le principe même d’OAuth. OAuth 2.1 le retire du standard. Pour l’authentification utilisateur, le Authorization Code Flow reste la seule option. Pour les flux purement machine-to-machine sans utilisateur impliqué, le Client Credentials Flow est la réponse appropriée.
Ce qui devient obligatoire : la sécurité par défaut
PKCE obligatoire pour tous les clients — la principale évolution d’OAuth 2.1
C’est — et de loin — le changement le plus structurant. PKCE (Proof Key for Code Exchange, prononcé « pixy ») était jusqu’ici recommandé uniquement pour les clients publics — typiquement les applications mobiles et les SPAs. OAuth 2.1 l’étend à tous les clients, y compris les clients confidentiels côté serveur.
Il ne s’agit pas simplement d’intégrer la RFC 7636 : c’est une rupture conceptuelle. Même un client confidentiel qui s’authentifie avec un secret doit désormais aussi utiliser PKCE. Les deux mécanismes sont complémentaires, pas substituables : le PKCE protège l’échange du code d’autorisation, l’authentification client protège l’identité du client auprès du token endpoint.
Comment PKCE fonctionne en pratique
À chaque demande d’autorisation, le client génère un code_verifier (chaîne aléatoire cryptographique d’au moins 43 caractères), en dérive un code_challenge par hash SHA-256 (méthode S256, recommandée et à privilégier), et l’envoie avec la requête initiale. Lors de l’échange du code contre un token, le client prouve qu’il possède le verifier original. Un attaquant qui intercepterait le code d’autorisation en transit ne pourrait pas l’exploiter sans ce secret éphémère.
Correspondance exacte des Redirect URIs
OAuth 2.0 permettait des correspondances flexibles sur les URIs de redirection : wildcards, sous-domaines, correspondances partielles. Cette souplesse a ouvert la voie aux attaques par open redirect. OAuth 2.1 impose une correspondance exacte, caractère par caractère, sans exception. Cela implique de revoir les configurations d’Authorization Server qui utilisent des patterns approximatifs.
Rotation des Refresh Tokens et interdiction dans les URLs
OAuth 2.1 recommande fortement la rotation des refresh tokens : chaque utilisation en génère un nouveau et invalide l’ancien. Pour les clients publics, la rotation ou le sender-constraining devient obligatoire. Par ailleurs, les access tokens ne peuvent plus transiter en query string — uniquement dans les Authorization headers ou le corps POST, éliminant ainsi le risque d’exfiltration via les logs de serveurs web.
Authentification client au token endpoint : une précision importante
Le draft OAuth 2.1 reconnaît les deux méthodes d’authentification client au token endpoint — client_secret_basic (crédentiels dans le header HTTP Authorization) et client_secret_post (crédentiels dans le corps de la requête) — sans en désigner une comme défaut normatif. Ce qui change fondamentalement, c’est que l’authentification client (quelle que soit la méthode) est désormais systématiquement combinée avec PKCE pour les clients confidentiels, là où les deux étaient précédemment indépendants.
Un point encore en évolution dans le draft
La spécification présente une ambiguïté sur l’inclusion du paramètre redirect_uri dans la requête de récupération du token : le texte normatif et les exemples du draft sont actuellement contradictoires sur ce point. Il est conseillé de conserver redirect_uri dans la requête token jusqu’à clarification officielle de l’IETF.
Tableau comparatif : OAuth 2.0 vs OAuth 2.1
Et OpenID Connect dans tout ça ?
OAuth 2.1 ne modifie pas directement la spécification OpenID Connect. Les flux OIDC impliquent des clients confidentiels qui s’authentifient auprès de l’Authorization Server — ils restent dans le cadre confidentiel avec authentification client. Selon les spécifications actuelles, PKCE n’est pas imposé dans les flux OIDC standard, bien que rien n’empêche de l’ajouter à titre de renforcement. À ce stade, aucune mise à jour formelle d’OpenID Connect n’est planifiée pour intégrer ces exigences, mais certaines implémentations choisissent d’ores et déjà d’appliquer PKCE dans les flux OIDC à titre de durcissement.
ClientFedID v2.0.14 : testez vos fournisseurs d’identité en mode OAuth 2.1
Chez Aduneo, nous avons traduit ces évolutions en capacités concrètes dans notre outil open source ClientFedID. La version 2.0.14, disponible depuis début 2026, intègre nativement le support d’OAuth 2.1 avec une adaptation majeure : il est désormais possible pour un client confidentiel de s’authentifier en combinant PKCE et authentification client, ce qui était impossible dans les versions précédentes.
L’outil propose des menus de préconfiguration permettant de basculer rapidement entre les quatre profils OAuth (2.0 et 2.1, client confidentiel ou public) :
Cette matrice vous permet de tester précisément le comportement de vos fournisseurs d’identité face à chaque profil : votre IdP supporte-t-il PKCE pour les clients confidentiels ? Rejette-t-il correctement les redirect_uri non exactes ? Répond-il correctement à une requête OAuth 2.1 complète ?
ClientFedID en pratique
ClientFedID est l’outil idéal pour vérifier la conformité de vos fournisseurs d’identité aux exigences OAuth 2.1 avant de passer en production. Facile à installer via PyPi ou Docker, il s’adresse aux intégrateurs IAM, consultants en sécurité et formateurs.
▶ Découvrir et télécharger ClientFedID
Un document pour les gouverner tous : la fin du patchwork de RFCs
L’un des bénéfices pratiques les plus concrets d’OAuth 2.1 est souvent sous-estimé : il réunit dans un seul document ce qui était dispersé entre RFC 6749, RFC 7636 (PKCE), RFC 8252 (Native Apps), RFC 9700 (Security BCP), et d’autres. Pour les équipes IAM, cela signifie une référence normative unique, des audits plus simples, et des implémentations moins sujettes aux omissions.
Un mot sur NIS2 et DORA
NIS2 s’applique aux entités des secteurs critiques (énergie, santé, infrastructures numériques…), tandis que DORA concerne spécifiquement les entités financières et leurs prestataires ICT. OAuth 2.1 n’est pas une exigence explicite de NIS2 ou de DORA — mais ses principes s’inscrivent directement dans les obligations de sécurité des authentifications que ces réglementations imposent. La suppression des flux dangereux, la rotation des tokens et le durcissement des redirections contribuent à l’exigence de « mesures techniques appropriées ». Les organisations déjà engagées dans une mise en conformité réglementaire ont tout intérêt à aligner leur stratégie OAuth en même temps.
Checklist : votre infrastructure est-elle prête pour OAuth 2.1 ?
Avant de migrer ou d’auditer vos systèmes, voici les points de contrôle essentiels :
- Point 1 —Avez-vous cartographié les applications qui utilisent encore l’Implicit Grant Flow ou le ROPC, et défini un plan de migration ?
- Point 2 — Vos Authorization Servers imposent-ils PKCE pour tous les clients, y compris les clients confidentiels ?
- Point 3 — Vos Redirect URIs sont-elles configurées avec correspondance exacte (pas de wildcard) ?
- Point 4 — La rotation des Refresh Tokens est-elle activée ? Les clients publics utilisent-ils des tokens sender-constrained ?
- Point 5 — Aucun access token n’est-il transmis en query string dans vos flux applicatifs ?
- Point 6 — Avez-vous testé la compatibilité OAuth 2.1 de vos fournisseurs d’identité avec ClientFedID v2.0.14 ?
Votre architecture OAuth est-elle à la hauteur des enjeux de sécurité actuels ?
Chez Aduneo, nous accompagnons les grandes organisations dans l’évaluation et la modernisation de leurs architectures IAM depuis plus de 20 ans. Nos experts analysent vos flux d’authentification existants, identifient les expositions liées aux pratiques OAuth obsolètes, et définissent avec vous un plan de migration pragmatique et priorisé.
Article rédigé par l’équipe Aduneo — Experts IAM depuis 2001
Aduneo
Expert cyber IAM depuis 2001
Spécialisés dans les domaines de la gestion des identités et des accès (IAM, CIAM, IGA, PAM, CIEM) et de la sécurité des infrastructures, nous aidons les organisations à sécuriser et à optimiser leurs environnements numériques on-premise, cloud et hybrides. Avec une expertise pointue dans ces secteurs critiques, nous comprenons les enjeux spécifiques de protection des données et d'accès sécurisé auxquels nos clients font face dans leur transformation digitale.
Démarrez tout de suite votre projet IAM avec nos équipes !
Nos agences
Nous contacter
Accès rapide
Related Posts
Sommaire
- Pourquoi parler d’OAuth 2.1 maintenant ?
- Ce qui disparaît : deux flux supprimés, une dette de sécurité effacée
- Ce qui devient obligatoire : la sécurité par défaut
- Tableau comparatif : OAuth 2.0 vs OAuth 2.1
- Et OpenID Connect dans tout ça ?
- ClientFedID v2.0.14 : testez vos fournisseurs d’identité en mode OAuth 2.1
- Un document pour les gouverner tous : la fin du patchwork de RFCs
- Un mot sur NIS2 et DORA
- Checklist : votre infrastructure est-elle prête pour OAuth 2.1 ?
Les standards de sécurité évoluent pour refléter les enseignements du terrain. OAuth 2.0, publié en 2012, a posé les bases de l’autorisation déléguée moderne et reste aujourd’hui le protocole de référence dans la très grande majorité des architectures IAM. OAuth 2.1 s’inscrit dans cette continuité : il consolide en un document unique les bonnes pratiques accumulées depuis plus d’une décennie, en rendant obligatoires des mécanismes jusqu’ici optionnels et en retirant des flux devenus incompatibles avec les exigences de sécurité actuelles. Pour les organisations qui gèrent des environnements d’authentification complexes, comprendre ces évolutions est essentiel pour anticiper les impacts sur leurs infrastructures et rester alignées avec les standards de l’industrie.
Pourquoi parler d’OAuth 2.1 maintenant ?
OAuth 2.0 est le standard d’autorisation déléguée sur lequel repose une part massive des architectures IAM modernes. Depuis sa publication en 2012 (RFC 6749), il a équipé des millions d’applications — des portails RH aux API métier, des applications mobiles aux plateformes cloud. Mais ce succès a eu un revers : au fil des années, OAuth 2.0 s’est enrichi de correctifs et de bonnes pratiques dispersés dans une douzaine de RFCs annexes, rendant les implémentations complexes et propices aux erreurs.
OAuth 2.1 est la réponse de l’IETF à ce problème. Ce n’est pas un nouveau protocole — c’est une consolidation rigoureuse. Un document unique qui balaie dix ans de retours d’expérience, supprime les flux dangereux, et rend obligatoires les bonnes pratiques jusqu’ici optionnelles. Le draft IETF en est aujourd’hui à sa version 14 (octobre 2025), avec une finalisation attendue prochainement.
Bien qu’encore à l’état de draft, OAuth 2.1 est déjà requis par des normes majeures. Anthropic en a fait la fondation du Model Context Protocol (MCP), qui définit comment les agents IA accèdent de manière sécurisée aux outils et données externes. C’est un signal fort : OAuth 2.1 n’est pas une évolution théorique, c’est une exigence opérationnelle qui émerge dès maintenant.
Ce qui disparaît : deux flux supprimés, une dette de sécurité effacée
L’Implicit Grant Flow — le flux qui exposait vos tokens dans l’URL
Conçu à l’origine pour les Single Page Applications (SPAs) qui ne pouvaient pas gérer d’échange côté serveur, l’Implicit Grant retournait directement le token d’accès dans le fragment d’URL (exemple.com#access_token=xyz). Ce token pouvait se retrouver dans l’historique du navigateur, les headers Referer ou les logs de proxy. OAuth 2.1 le supprime définitivement. Les SPAs doivent désormais utiliser le Authorization Code Flow avec PKCE.
Le Resource Owner Password Credentials (ROPC) — la collecte de mots de passe déguisée
Ce flux permettait à une application de collecter directement login et mot de passe pour les transmettre à l’Authorization Server — une pratique qui contredisait le principe même d’OAuth. OAuth 2.1 le retire du standard. Pour l’authentification utilisateur, le Authorization Code Flow reste la seule option. Pour les flux purement machine-to-machine sans utilisateur impliqué, le Client Credentials Flow est la réponse appropriée.
Ce qui devient obligatoire : la sécurité par défaut
PKCE obligatoire pour tous les clients — la principale évolution d’OAuth 2.1
C’est — et de loin — le changement le plus structurant. PKCE (Proof Key for Code Exchange, prononcé « pixy ») était jusqu’ici recommandé uniquement pour les clients publics — typiquement les applications mobiles et les SPAs. OAuth 2.1 l’étend à tous les clients, y compris les clients confidentiels côté serveur.
Il ne s’agit pas simplement d’intégrer la RFC 7636 : c’est une rupture conceptuelle. Même un client confidentiel qui s’authentifie avec un secret doit désormais aussi utiliser PKCE. Les deux mécanismes sont complémentaires, pas substituables : le PKCE protège l’échange du code d’autorisation, l’authentification client protège l’identité du client auprès du token endpoint.
Comment PKCE fonctionne en pratique
À chaque demande d’autorisation, le client génère un code_verifier (chaîne aléatoire cryptographique d’au moins 43 caractères), en dérive un code_challenge par hash SHA-256 (méthode S256, recommandée et à privilégier), et l’envoie avec la requête initiale. Lors de l’échange du code contre un token, le client prouve qu’il possède le verifier original. Un attaquant qui intercepterait le code d’autorisation en transit ne pourrait pas l’exploiter sans ce secret éphémère.
Correspondance exacte des Redirect URIs
OAuth 2.0 permettait des correspondances flexibles sur les URIs de redirection : wildcards, sous-domaines, correspondances partielles. Cette souplesse a ouvert la voie aux attaques par open redirect. OAuth 2.1 impose une correspondance exacte, caractère par caractère, sans exception. Cela implique de revoir les configurations d’Authorization Server qui utilisent des patterns approximatifs.
Rotation des Refresh Tokens et interdiction dans les URLs
OAuth 2.1 recommande fortement la rotation des refresh tokens : chaque utilisation en génère un nouveau et invalide l’ancien. Pour les clients publics, la rotation ou le sender-constraining devient obligatoire. Par ailleurs, les access tokens ne peuvent plus transiter en query string — uniquement dans les Authorization headers ou le corps POST, éliminant ainsi le risque d’exfiltration via les logs de serveurs web.
Authentification client au token endpoint : une précision importante
Le draft OAuth 2.1 reconnaît les deux méthodes d’authentification client au token endpoint — client_secret_basic (crédentiels dans le header HTTP Authorization) et client_secret_post (crédentiels dans le corps de la requête) — sans en désigner une comme défaut normatif. Ce qui change fondamentalement, c’est que l’authentification client (quelle que soit la méthode) est désormais systématiquement combinée avec PKCE pour les clients confidentiels, là où les deux étaient précédemment indépendants.
Un point encore en évolution dans le draft
La spécification présente une ambiguïté sur l’inclusion du paramètre redirect_uri dans la requête de récupération du token : le texte normatif et les exemples du draft sont actuellement contradictoires sur ce point. Il est conseillé de conserver redirect_uri dans la requête token jusqu’à clarification officielle de l’IETF.
Tableau comparatif : OAuth 2.0 vs OAuth 2.1
Et OpenID Connect dans tout ça ?
OAuth 2.1 ne modifie pas directement la spécification OpenID Connect. Les flux OIDC impliquent des clients confidentiels qui s’authentifient auprès de l’Authorization Server — ils restent dans le cadre confidentiel avec authentification client. Selon les spécifications actuelles, PKCE n’est pas imposé dans les flux OIDC standard, bien que rien n’empêche de l’ajouter à titre de renforcement. À ce stade, aucune mise à jour formelle d’OpenID Connect n’est planifiée pour intégrer ces exigences, mais certaines implémentations choisissent d’ores et déjà d’appliquer PKCE dans les flux OIDC à titre de durcissement.
ClientFedID v2.0.14 : testez vos fournisseurs d’identité en mode OAuth 2.1
Chez Aduneo, nous avons traduit ces évolutions en capacités concrètes dans notre outil open source ClientFedID. La version 2.0.14, disponible depuis début 2026, intègre nativement le support d’OAuth 2.1 avec une adaptation majeure : il est désormais possible pour un client confidentiel de s’authentifier en combinant PKCE et authentification client, ce qui était impossible dans les versions précédentes.
L’outil propose des menus de préconfiguration permettant de basculer rapidement entre les quatre profils OAuth (2.0 et 2.1, client confidentiel ou public) :
Cette matrice vous permet de tester précisément le comportement de vos fournisseurs d’identité face à chaque profil : votre IdP supporte-t-il PKCE pour les clients confidentiels ? Rejette-t-il correctement les redirect_uri non exactes ? Répond-il correctement à une requête OAuth 2.1 complète ?
ClientFedID en pratique
ClientFedID est l’outil idéal pour vérifier la conformité de vos fournisseurs d’identité aux exigences OAuth 2.1 avant de passer en production. Facile à installer via PyPi ou Docker, il s’adresse aux intégrateurs IAM, consultants en sécurité et formateurs.
▶ Découvrir et télécharger ClientFedID
Un document pour les gouverner tous : la fin du patchwork de RFCs
L’un des bénéfices pratiques les plus concrets d’OAuth 2.1 est souvent sous-estimé : il réunit dans un seul document ce qui était dispersé entre RFC 6749, RFC 7636 (PKCE), RFC 8252 (Native Apps), RFC 9700 (Security BCP), et d’autres. Pour les équipes IAM, cela signifie une référence normative unique, des audits plus simples, et des implémentations moins sujettes aux omissions.
Un mot sur NIS2 et DORA
NIS2 s’applique aux entités des secteurs critiques (énergie, santé, infrastructures numériques…), tandis que DORA concerne spécifiquement les entités financières et leurs prestataires ICT. OAuth 2.1 n’est pas une exigence explicite de NIS2 ou de DORA — mais ses principes s’inscrivent directement dans les obligations de sécurité des authentifications que ces réglementations imposent. La suppression des flux dangereux, la rotation des tokens et le durcissement des redirections contribuent à l’exigence de « mesures techniques appropriées ». Les organisations déjà engagées dans une mise en conformité réglementaire ont tout intérêt à aligner leur stratégie OAuth en même temps.
Checklist : votre infrastructure est-elle prête pour OAuth 2.1 ?
Avant de migrer ou d’auditer vos systèmes, voici les points de contrôle essentiels :
- Point 1 —Avez-vous cartographié les applications qui utilisent encore l’Implicit Grant Flow ou le ROPC, et défini un plan de migration ?
- Point 2 — Vos Authorization Servers imposent-ils PKCE pour tous les clients, y compris les clients confidentiels ?
- Point 3 — Vos Redirect URIs sont-elles configurées avec correspondance exacte (pas de wildcard) ?
- Point 4 — La rotation des Refresh Tokens est-elle activée ? Les clients publics utilisent-ils des tokens sender-constrained ?
- Point 5 — Aucun access token n’est-il transmis en query string dans vos flux applicatifs ?
- Point 6 — Avez-vous testé la compatibilité OAuth 2.1 de vos fournisseurs d’identité avec ClientFedID v2.0.14 ?
Votre architecture OAuth est-elle à la hauteur des enjeux de sécurité actuels ?
Chez Aduneo, nous accompagnons les grandes organisations dans l’évaluation et la modernisation de leurs architectures IAM depuis plus de 20 ans. Nos experts analysent vos flux d’authentification existants, identifient les expositions liées aux pratiques OAuth obsolètes, et définissent avec vous un plan de migration pragmatique et priorisé.
Article rédigé par l’équipe Aduneo — Experts IAM depuis 2001
