Comprendre les enjeux de l’authentification moderne

Dans un contexte où l’identité est devenue le nouveau périmètre de sécurité, les protocoles d’authentification ne sont plus un sujet réservé aux développeurs. Ils sont au cœur des décisions d’architecture, des projets de transformation cloud, et des obligations réglementaires croissantes.

Selon le rapport Verizon DBIR 2024, plus de 80 % des violations de données impliquent des identifiants compromis. Ce chiffre rappelle que la robustesse d’un système de sécurité dépend, en premier lieu, de la qualité de ses mécanismes d’authentification.

Qu’il s’agisse de déployer une stratégie Zero Trust, de mettre en place un Single Sign-On (SSO) multi-applications, de sécuriser des API exposées, ou d’adresser les exigences de NIS2 et DORA, vous serez inévitablement confronté au choix d’un protocole d’authentification — et ce choix a des conséquences durables sur votre architecture IAM.

Définition : Un protocole d’authentification définit la manière dont un utilisateur (ou un système) prouve son identité à une application ou un service. Dans les architectures modernes, ces protocoles permettent à des applications de déléguer la vérification d’identité à un fournisseur d’identité centralisé (Identity Provider, IdP) — tout en maintenant une sécurité et une traçabilité rigoureuses.

Trois standards dominent aujourd’hui le paysage de l’authentification fédérée : SAML 2.0, OAuth 2.0 et OpenID Connect. Chacun répond à des besoins distincts et présente des avantages et des limites que nous allons détailler.

 

SAML, OAuth 2.0, OpenID Connect : ce que chaque protocole fait vraiment

SAML (Security Assertion Markup Language)

SAML 2.0 est un protocole basé sur XML, standardisé en 2005 par l’OASIS. Il a été conçu pour répondre aux besoins des grandes entreprises : SSO inter-organisationnel, fédération d’identités entre partenaires, intégration avec les annuaires d’entreprise.

Comment fonctionne SAML 2.0 ?

1. L’utilisateur tente d’accéder à une application (Service Provider, SP)
2. Le SP redirige l’utilisateur vers le fournisseur d’identité (Identity Provider, IdP)
3. Après authentification, l’IdP génère une assertion SAML signée numériquement
4. Cette assertion est transmise au SP, qui valide l’identité et autorise l’accès

Forces de SAML 2.0

• Standard éprouvé depuis plus de 20 ans, avec un écosystème très large
• Sécurité robuste basée sur les signatures XML (xmldsig) et le chiffrement (xmlenc)
• Compatibilité native avec la majorité des solutions d’entreprise (SAP, Salesforce, ServiceNow, solutions on-premise…)
• Support des cas d’usage de fédération inter-organisationnelle complexes

Limites de SAML 2.0

• XML verbeux et complexe à implémenter correctement — les erreurs de configuration sont fréquentes et difficiles à déboguer
• Inadapté aux applications mobiles natives et aux architectures API-first
• Pas de support natif pour la délégation d’autorisation (accès aux API)
• Difficile à intégrer dans des architectures microservices

À noter : SAML reste un standard incontournable pour les applications legacy d’entreprise et la fédération inter-organisationnelle. Sa disparition n’est pas à l’ordre du jour — mais les nouvelles implémentations s’orientent massivement vers OpenID Connect. 

OAuth 2.0

Contrairement à une idée reçue très répandue, OAuth 2.0 n’est pas un protocole d’authentification. C’est un framework de délégation d’autorisation (RFC 6749). Il permet à une application d’accéder à des ressources protégées au nom d’un utilisateur, sans que celui-ci n’ait à partager ses identifiants avec cette application.

La confusion est compréhensible — OAuth 2.0 implique bien une étape d’authentification — mais le standard lui-même ne définit pas comment prouver l’identité d’un utilisateur. C’est précisément le rôle d’OpenID Connect.

Comment fonctionne OAuth 2.0 ?

1. L’application (client) demande l’autorisation d’accéder à des ressources protégées
2. L’utilisateur s’authentifie auprès du serveur d’autorisation et donne son consentement
3. Un access token est délivré à l’application, limité aux scopes autorisés
4. L’application utilise cet access token pour accéder aux ressources protégées (API, données…)

Forces d’OAuth 2.0

• Léger, basé sur HTTP et JSON — facile à intégrer dans tout environnement
• Parfaitement adapté aux architectures API et microservices
• Granularité fine des autorisations via le système de scopes
• Standard universel pour l’accès délégué aux ressources cloud

Limites d’OAuth 2.0

• Ne gère pas l’authentification des utilisateurs — utiliser OAuth seul pour « s’authentifier » est une erreur d’architecture courante et dangereuse
• Multitude de flux (flows) qui peuvent prêter à confusion et générer des implémentations incorrectes
• Risques de sécurité significatifs en cas de mauvaise implémentation (vol de token, confused deputy attack…)

« Le choix du protocole d’authentification détermine non seulement la sécurité de vos accès, mais aussi l’expérience utilisateur et la flexibilité future de votre architecture IAM. »

OpenID Connect (OIDC)

OpenID Connect est une couche d’identité construite au-dessus d’OAuth 2.0 (spécification publiée en 2014). Il résout précisément la lacune d’OAuth : il standardise l’authentification des utilisateurs en introduisant un ID Token (JWT signé) qui contient les informations d’identité de l’utilisateur.

Comment fonctionne OpenID Connect ?

1. Le client déclenche un flux OAuth 2.0 avec le scope openid
2. Après authentification, le serveur d’autorisation émet un ID Token (JWT signé) et un access token
3. L’ID Token contient des claims standardisés sur l’identité (sub, email, name, iss, aud, exp…)
4. Le client peut appeler l’endpoint /userinfo pour obtenir des claims supplémentaires

Forces d’OpenID Connect

• Standard moderne, basé sur JSON et JWT — léger et facile à intégrer
• Parfaitement adapté aux applications web, SPA et mobiles contemporaines
• Bibliothèques clientes disponibles dans tous les langages majeurs
• Standardisation des claims d’identité — interopérabilité garantie
• Base technique de nombreux standards émergents (OpenID4VP, EUDI Wallet…)

Limites d’OpenID Connect

• Support incomplet dans certaines applications legacy (qui ne supportent que SAML)
• Gestion des scopes et claims peut devenir complexe dans des environnements multi-tenant
• Nécessite une bonne maîtrise de la validation des JWT côté client

 

Si SAML, OAuth 2 et OpenID Connect dominent largement le marché, le protocole d’authentification CAS reste bien implanté notamment dans le secteur public

Tableau comparatif des trois protocoles

OAuth 2.1 et les évolutions de sécurité à connaître

OAuth 2.1 : la consolidation en cours

OAuth 2.1 n’est pas une révolution — c’est une consolidation des bonnes pratiques accumulées depuis 10 ans d’expérience en production. Le draft (en cours de finalisation à l’IETF) supprime les flows considérés comme dangereux et rend obligatoires les mécanismes de sécurité qui étaient jusqu’ici optionnels.

Les changements clés qu’OAuth 2.1 impose :

• Suppression de l’Implicit Flow — ne doit plus être utilisé dans aucune nouvelle implémentation
• Suppression du Resource Owner Password Credentials (ROPC) Flow
• PKCE obligatoire pour tous les clients — y compris les applications web confidentielles (voir ci-dessous)
• Refresh tokens rotatifs — un refresh token utilisé ne peut plus être réutilisé
• Restriction des redirect URIs — la correspondance exacte est obligatoire

⚠️ Si votre architecture utilise encore l’Implicit Flow ou le ROPC Flow, une mise à jour s’impose indépendamment d’OAuth 2.1 — ces flows sont déjà considérés comme non conformes par les principaux guides de sécurité (ANSSI, OWASP, NIST).

→ Pour une analyse détaillée des impacts sur vos implémentations, consultez notre article OAuth 2.0 vs OAuth 2.1 : ce qui change pour les équipes IAM

PKCE : obligatoire, pas optionnel

PKCE (Proof Key for Code Exchange, RFC 7636) est un mécanisme de sécurité qui protège le flux Authorization Code contre les attaques par interception du code d’autorisation. Son principe : le client génère un code_verifier secret et envoie son hash (code_challenge) avec la requête d’autorisation. L’IdP vérifie la correspondance lors de l’échange du code contre un token.

Longtemps présenté comme une mesure spécifique aux clients publics (applications mobiles, SPA), PKCE est aujourd’hui recommandé pour tous les types de clients, y compris les applications web confidentielles. OAuth 2.1 le rend obligatoire sans exception.

Si votre IdP ou vos applications ne supportent pas encore PKCE, c’est un point à adresser dans votre roadmap IAM.

DPoP : lier les tokens à l’expéditeur

DPoP (Demonstrating Proof of Possession, RFC 9449) va plus loin dans la sécurisation des access tokens. Il permet de lier cryptographiquement un token à la clé privée du client qui l’a obtenu. Résultat : un token volé en transit est inutilisable par un attaquant qui ne possède pas la clé privée correspondante.

DPoP s’intègre avec OAuth 2.0 et OpenID Connect, et représente l’état de l’art pour les architectures où le vol de tokens est un vecteur d’attaque à traiter sérieusement — notamment dans les environnements zero trust et les architectures micro-services exposées.

Le pattern BFF pour les Single Page Applications

L’article recommande OpenID Connect pour les SPA (Single Page Applications) — c’est correct — mais la recommandation de sécurité dominante en 2026 est d’éviter de stocker des tokens côté navigateur. Le pattern BFF (Backend For Frontend) adresse ce problème : un backend léger dédié à chaque frontend prend en charge le flux OAuth/OIDC et maintient la session, sans exposer de tokens dans le JavaScript côté client.

Ce pattern est aujourd’hui recommandé par l’OWASP et soutenu par des frameworks comme Spring Security et Next.js Auth. Si vous gérez des SPA manipulant des données sensibles, le BFF doit faire partie de votre design d’architecture.

Comment choisir le protocole adapté à votre contexte ?

Le choix du protocole d’authentification dépend de plusieurs facteurs, notamment :

Type d’applications à sécuriser 

Environnement technique

• Écosystème Microsoft (Entra ID / Azure AD) : privilégie OpenID Connect et OAuth 2.0, supporte SAML pour les applications legacy
• Google Workspace : OpenID Connect nativement
• Applications Java d’entreprise historiques : souvent SAML — évaluer la faisabilité d’une migration OIDC
• Keycloak : supporte nativement SAML 2.0, OpenID Connect, OAuth 2.0 et PKCE — excellent point de convergence pour les architectures hybrides

 

Outil open source : Aduneo a développé ClientFedID, un outil de test de fournisseurs d’identité couvrant SAML 2.0, OAuth 2.0 et OpenID Connect. Il permet de vérifier la conformité de vos IdP et de diagnostiquer les problèmes d’implémentation en environnement de recette.

 

L’architecture hybride : la réalité des grandes organisations

Dans la pratique, les organisations de plus de 2 000 collaborateurs n’ont pas le luxe de choisir un seul protocole. Elles héritent de plusieurs décennies d’applications dont les contraintes d’intégration sont hétérogènes.

La clé est de disposer d’un Identity Provider capable d’orchestrer SAML, OAuth 2.0 et OpenID Connect de façon centralisée, tout en offrant une expérience utilisateur cohérente (SSO unifié, MFA centralisée, politiques d’accès contextuelles).

Exemple d’architecture hybride typique chez un grand compte français :

• OpenID Connect pour les applications SaaS cloud (Microsoft 365, Salesforce, outils DevOps)
• SAML pour les applications legacy on-premise (ERP, portails métier historiques)
• OAuth 2.0 pour la sécurisation des API internes et l’accès aux microservices
• Le tout piloté par un IdP central (Ping Identity, Entra ID, Keycloak…) assurant le SSO unifié

 

Architecture hybride : la cohabitation des protocoles

Dans la réalité, les grandes organisations utilisent souvent plusieurs protocoles simultanément. La clé est d’avoir une architecture IAM capable d’orchestrer ces différents mécanismes tout en offrant une expérience utilisateur cohérente.

C’est notamment le rôle des solutions de fédération d’identités et des Identity Providers modernes, qui peuvent servir de pont entre ces différents protocoles.

Exemple concret : Une entreprise peut utiliser OpenID Connect pour ses applications SaaS cloud, maintenir SAML pour ses applications legacy internes, et sécuriser ses API avec OAuth 2.0, le tout piloté par une solution de gestion des identités centralisée.

 

Protocoles d’authentification et conformité réglementaire

Le choix d’un protocole d’authentification n’est pas uniquement une décision technique. En 2026, plusieurs réglementations imposent des exigences directes sur vos mécanismes d’authentification.

NIS2 : l’authentification forte comme obligation

La directive NIS2, transposée en droit français depuis octobre 2024, impose aux entités essentielles et importantes des mesures de sécurité des systèmes d’information incluant explicitement l’authentification multi-facteurs pour l’accès aux systèmes critiques. Le choix d’un protocole d’authentification robuste (OpenID Connect ou SAML avec MFA) et correctement implémenté (PKCE, rotation des tokens, durée de vie courte) s’inscrit directement dans la conformité NIS2.

DORA : la résilience de l’authentification dans le secteur financier

Le règlement DORA (Digital Operational Resilience Act), applicable depuis janvier 2025, impose aux entités financières de démontrer la résilience de leurs systèmes d’information, y compris leurs mécanismes d’authentification et de gestion des accès. Cela implique notamment la capacité à auditer les flux d’authentification, à détecter les anomalies de comportement, et à garantir la disponibilité des services d’authentification (IdP, STS).

eIDAS 2.0 et l’EUDI Wallet : l’identité numérique souveraine

Le règlement eIDAS 2.0 et le projet d’EUDI Wallet (European Digital Identity Wallet) introduisent un nouveau paradigme : le citoyen européen disposera d’un portefeuille d’identité numérique souverain, utilisable pour s’authentifier auprès des services publics et privés. Ce wallet repose sur le protocole OpenID for Verifiable Presentations (OpenID4VP), une extension d’OpenID Connect.

Pour les organisations qui exposent des services aux citoyens (secteur public, banques, assurances, e-commerce…), anticiper la compatibilité OpenID4VP dans leurs architectures CIAM est une décision stratégique à prendre dès aujourd’hui.

Pour approfondir : OpenID Connect et OpenID4VP : comprendre le futur protocole d’identité

Les tendances de l’authentification

La consolidation d’OpenID Connect comme standard dominant

OpenID Connect s’est imposé comme le standard de facto pour les nouvelles implémentations. Cette domination s’explique par sa flexibilité, la richesse de son écosystème, et son adoption par tous les grands providers cloud. Les nouvelles applications — web, mobile, SaaS — choisissent quasi-systématiquement OIDC.

L’authentification sans mot de passe (passwordless)

WebAuthn et FIDO2 s’intègrent désormais avec OpenID Connect pour permettre une authentification forte sans mot de passe. Passkeys, authentification biométrique, clés de sécurité matérielles — ces mécanismes réduisent drastiquement la surface d’attaque liée au phishing et au vol de credentials. Les IdP modernes (Ping Identity, Entra ID, Keycloak 26+) supportent ces standards nativement.

La sécurisation renforcée des tokens

Face à l’augmentation des attaques ciblant les tokens d’authentification (vol en transit, replay attacks), les meilleures pratiques évoluent vers :

• Tokens à durée de vie courte (quelques minutes pour les access tokens)
• DPoP pour lier les tokens à la clé du client
• Rotation des refresh tokens
• Validation stricte des audiences (aud) et des issuers (iss)
• Chiffrement des ID Tokens en plus de leur signature (JWE)

L’identité agentique : les IA aussi s’authentifient

L’émergence des agents IA (LLM avec accès à des outils, workflows automatisés, assistants autonomes) crée un nouveau défi pour les équipes IAM : comment authentifier et autoriser des agents logiciels qui agissent au nom d’utilisateurs ou en toute autonomie ? OAuth 2.0 Client Credentials et les service accounts sont aujourd’hui les mécanismes utilisés par défaut, mais les questions de traçabilité, de least privilege et de révocation pour des agents à durée de vie variable sont en train d’être adressées par de nouveaux profils (notamment dans le cadre du protocole MCP d’Anthropic).

Pour aller plus loin sur ce sujet : notre article sur IAM et intelligence artificielle agentique

SCIM : le provisioning corrélé à l’authentification

La montée en puissance de SCIM (System for Cross-domain Identity Management) mérite d’être mentionnée ici. SCIM ne gère pas l’authentification, mais il est le pendant indispensable d’OpenID Connect pour le provisioning automatisé des identités dans les applications SaaS. Une architecture IAM moderne articule OIDC (authentification), OAuth 2.0 (autorisation) et SCIM (cycle de vie des identités).

Découvrez les bonnes pratiques d’authentification pour sécuriser vos applications et systèmes d’information dans notre nouvel article de blog dédié sur le sujet

 

Les recommandations d’Aduneo

Chez Aduneo, nous accompagnons depuis plus de 20 ans des organisations dans la conception et la mise en œuvre de leurs architectures d’authentification. Voici ce que nous recommandons en 2026.

Choisir OpenID Connect par défaut pour les nouveaux projets

Sauf contrainte explicite (application legacy sans support OIDC, partenaire imposant SAML), OpenID Connect est le standard à privilégier pour tout nouveau projet. Ses avantages en termes de maintenabilité, de sécurité (PKCE, DPoP), et d’interopérabilité avec les standards émergents (OpenID4VP) en font le choix le plus durable.

Ne pas négliger la sécurité d’implémentation

Un protocole robuste mal implémenté est plus dangereux qu’un protocole moins sophistiqué bien implémenté. Les points de vigilance récurrents que nous observons en audit :

• Validation insuffisante des ID Tokens (audience, expiration, signature)
• Implicit Flow encore utilisé dans des SPA
• Redirect URIs trop permissives
• Refresh tokens sans rotation ni expiration
• Absence de PKCE sur des flows Authorization Code
• Secrets clients exposés dans le code source ou les logs

Adopter une approche progressive pour SAML → OIDC

La migration d’applications SAML vers OIDC ne se fait pas en une nuit. Notre approche recommandée : déployer un IdP central supportant les deux protocoles, migrer les applications par vague (en commençant par les plus récentes et les plus stratégiques), et utiliser des proxies d’authentification pour les cas où la migration directe n’est pas envisageable à court terme.

Checklist de sécurité pour vos implémentations

PKCE activé sur tous les flows Authorization Code

Implicit Flow désactivé ou non supporté

Durée de vie des access tokens ≤ 15 minutes

Refresh tokens rotatifs avec expiration

Validation stricte des JWT (signature, audience, issuer, expiration)

Redirect URIs en correspondance exacte

MFA activé pour tous les accès sensibles

Rotation régulière des clés de signature (JWKS)

Logs d’authentification centralisés et auditables

DPoP évalué pour les flux exposés à un risque élevé de vol de token

Conclusion

Le choix du protocole d’authentification est une décision d’architecture à long terme. SAML 2.0 reste un standard solide pour les applications legacy et la fédération inter-organisationnelle, et sa disparition n’est pas à l’ordre du jour. OAuth 2.0 est indispensable pour toute architecture API. OpenID Connect s’impose comme le standard moderne pour l’authentification des utilisateurs dans les environnements web, mobile et cloud.

Mais au-delà du choix du protocole, c’est la qualité de l’implémentation qui fait la différence — PKCE, DPoP, gestion des tokens, politiques MFA. Et en 2026, cette implémentation doit tenir compte d’un contexte réglementaire (NIS2, DORA, eIDAS 2.0) et technologique (OAuth 2.1, identité agentique, EUDI Wallet) en évolution rapide.

Vous êtes en train d’auditer votre architecture d’authentification existante, de préparer une migration SAML → OIDC, ou de définir la stack IAM d’un nouveau projet ? Nos experts sont disponibles pour un premier échange.

 

FAQ – Protocoles d’authentification

Quelle est la différence principale entre OAuth 2.0 et OpenID Connect ?

OAuth 2.0 est un framework de délégation d’autorisation : il permet à une application d’accéder à des ressources protégées au nom d’un utilisateur. Il ne définit pas comment prouver l’identité de l’utilisateur. OpenID Connect ajoute cette couche d’authentification en introduisant un ID Token (JWT signé) qui contient les informations d’identité. En pratique : OAuth 2.0 répond à « cette application peut-elle accéder à ces ressources ? », OIDC répond à « qui est cet utilisateur ? ».

SAML est-il obsolète en 2026 ?

Non. SAML 2.0 reste largement déployé dans les grandes entreprises, notamment pour les applications legacy, les solutions ERP, et la fédération inter-organisationnelle. Sa robustesse et son écosystème de 20 ans en font un standard durable. En revanche, les nouvelles implémentations s’orientent quasi-systématiquement vers OpenID Connect, qui offre une meilleure intégration avec les architectures modernes.

Qu’est-ce que PKCE et pourquoi est-ce important ?

PKCE (Proof Key for Code Exchange) est un mécanisme de sécurité qui protège le flux Authorization Code d’OAuth 2.0 contre l’interception du code d’autorisation. Le client génère un secret aléatoire (code_verifier), envoie son hash à l’IdP lors de la demande d’autorisation, et prouve qu’il possède le secret lors de l’échange du code contre un token. OAuth 2.1 rend PKCE obligatoire pour tous les types de clients — si votre implémentation ne l’utilise pas encore, c’est une priorité de sécurité.

Quel protocole pour sécuriser des API REST ?

OAuth 2.0 est le standard pour la sécurisation d’API REST. Il permet une granularité fine des autorisations (scopes), une délégation d’accès sans partage de credentials, et une intégration naturelle dans les architectures microservices. Pour les communications machine-to-machine (services sans utilisateur), le flow Client Credentials est la solution appropriée.

Comment migrer progressivement de SAML vers OpenID Connect ?

La démarche recommandée chez Aduneo : (1) déployer un IdP central supportant les deux protocoles (Ping Identity, Keycloak, Entra ID…), (2) établir une cartographie des applications SAML par criticité et faisabilité de migration, (3) migrer par vagues en commençant par les applications les plus récentes et les plus stratégiques, (4) utiliser des proxies d’authentification pour les applications legacy dont la migration directe n’est pas envisageable à court terme. Cette approche permet de maintenir le SSO et l’expérience utilisateur tout au long de la transition.

OpenID Connect est-il compatible avec eIDAS 2.0 et l’EUDI Wallet ?

Oui. Le protocole OpenID for Verifiable Presentations (OpenID4VP), qui est la base technique de l’EUDI Wallet, est une extension d’OpenID Connect. Les organisations qui anticipent l’intégration avec le wallet d’identité européen ont donc intérêt à consolider leur maîtrise d’OpenID Connect dès maintenant.

Cet article a été rédigé et mis à jour par l’équipe d’experts IAM d’Aduneo. Pour approfondir ces sujets :

• • OAuth 2.0 vs OAuth 2.1 : ce qui change pour les équipes IAM
  • OpenID Connect et OpenID4VP : comprendre le futur protocole d’identité
  • Testez vos fournisseurs d’identité avec ClientFedID
  • Bonnes pratiques d’authentification pour sécuriser vos accès
  • CAS : un protocole d’authentification toujours d’actualité