Lectures: 9
Résumé – Face à la multiplication des architectures distribuées et SaaS, la gestion des identités (authentification vs autorisation) se complexifie et expose à des failles et expériences utilisateur dégradées. SAML joue sur la robustesse XML pour la fédération enterprise, OAuth 2.0 fournit la délégation d’accès via JWT et OIDC combine ces flux pour l’authentification moderne, tandis que SSO centralisé améliore productivité et gouvernance.
Solution : adapter ou mixer ces standards selon intranet B2E, APIs B2B ou appli B2C mobile, piloter flux, scopes et cycle de vie, orchestrer via gateway d’identité et prévoir audits, rotation de clés et modularité pour une identité agile et sécurisée.
À l’ère des architectures distribuées, la gestion des identités et des accès est devenue un pilier de la sécurité et de l’expérience utilisateur. Authentification et autorisation sont souvent confondues, tandis que SSO, SAML, OAuth 2.0 et OIDC se retrouvent mal mis en œuvre. Pourtant, ces standards sont essentiels pour garantir la cohérence et la sécurité dans les environnements SaaS, microservices et mobiles. Cet article propose une analyse claire et opérationnelle des distinctions fondamentales, des mécanismes techniques et des cas d’usage associés. Il vise à outiller les décideurs techniques et métiers dans le choix et la combinaison des bons protocoles pour une identité numérique robuste, évolutive et sécurisée.
Fondations de l’identité et accès
Il est crucial de différencier l’authentification (vérification de l’identité) de l’autorisation (attribution de droits d’accès). Ces deux concepts reposent sur des mécanismes et des protocoles distincts qu’il convient de maîtriser pour éviter les failles et optimiser l’expérience utilisateur.
Authentification et autorisation, deux facettes complémentaires
L’authentification consiste à confirmer qu’un utilisateur est bien qui il prétend être, généralement via un couple identifiant/mot de passe, une clé matérielle ou une authentification multifacteur. Elle répond à la question “Qui est-ce ?”.
L’autorisation intervient une fois l’identité établie, pour déterminer les ressources et les opérations accessibles. Elle répond à la question “Qu’a-t-il le droit de faire ?”. Confondre ces deux notions peut conduire à des configurations où un utilisateur authentifié accède à des données sensibles sans contrôle adéquat.
Dans une architecture d’entreprise, un Identity Provider (IdP) gère l’authentification et émet des tokens, tandis que chaque Service Provider (SP) consomme ces tokens pour appliquer des règles d’autorisation. C’est ce modèle qui permet d’isoler les responsabilités et de garantir une gouvernance claire.
Tokens, flux et formats : XML vs JSON/JWT
Les standards historiques, comme SAML, utilisent des échanges XML pour véhiculer des assertions d’identité et d’attributs entre l’IdP et le SP. Ces documents sont signés et permettent un modèle fédéré robuste, mais peuvent être relativement volumineux et complexes à traiter.
En contraste, OAuth 2.0 et OIDC exploitent des JSON Web Tokens (JWT) : des objets JSON encodés et signés, plus légers, plus facilement manipulables dans des environnements web et mobiles. Les JWT contiennent un ensemble de claims (attributs), une signature et parfois un chiffrement.
Les flux OAuth 2.0 standard (authorization code, client credentials…) définissent comment obtenir et rafraîchir des access tokens, tandis qu’OIDC enrichit ces flux avec des ID tokens dédiés à l’authentification. Comprendre ces flux est essentiel pour sécuriser correctement chaque étape de l’échange d’informations.
Cette évolution vers JSON/JWT facilite l’intégration dans des architectures API-first et des microservices, offrant une latence réduite et une flexibilité accrue pour des applications mobiles et serverless.
Identity Provider vs Service Provider
Un IdP centralise l’authentification : il stocke les identités, gère les politiques de sécurité (mots de passe, MFA), et émet des assertions ou tokens. Il doit être hautement disponible et auditable.
Un SP est tout composant qui reçoit une preuve d’identité (assertion SAML, JWT OIDC) et se base sur ces informations pour autoriser l’accès à ses ressources. Un SP peut être une application web, un service API ou une application mobile.
La fédération d’identités permet à plusieurs SP de déléguer l’authentification à un ou plusieurs IdP. Les standards SAML et OIDC sont souvent utilisés pour établir une confiance inter-organisationnelle, comme dans des scénarios B2B ou campus.
Standards d’authentification
SSO, SAML, OAuth 2.0 et OIDC ne sont pas interchangeables : chacun répond à des besoins et des architectures spécifiques. Le choix dépend du contexte organisationnel, des exigences de sécurité et des cas d’usage visés.
Single Sign-On (SSO) : l’expérience utilisateur comme priorité
Le SSO vise à offrir une authentification unique pour accéder à plusieurs applications sans ressaisir ses identifiants. C’est un mécanisme transversal reposant souvent sur SAML ou OIDC pour échanger les informations d’authentification.
Ce modèle améliore la productivité des utilisateurs et réduit la gestion des mots de passe. En entreprise, il permet de centraliser la politique de sécurité et d’appliquer des contrôles uniformes (enforcement de MFA, verrouillage de compte…).
Le principal enjeu reste la robustesse des certificats et la gestion du cycle de vie des sessions pour éviter qu’une compromission d’une session n’impacte l’ensemble des services accessibles via SSO.
SAML : le standard historique de la fédération en environnements enterprise
SAML 2.0 est largement utilisé dans les grandes organisations et les interconnexions B2B (fédérations académiques, intranets d’entreprises). Il repose sur des assertions XML signées entre un IdP et un SP.
Ses atouts : sécurité éprouvée, granularité des attributs, support de scénarios complexes (authn contexts, nameID policies). Ses limites : complexité de mise en œuvre, poids des échanges, dépendance à un parsing XML. Il reste solide pour des communautés d’organisations ayant besoin d’une fédération de confiance.
Exemple : une entreprise de fabrication suisse de taille intermédiaire a adopté SAML pour son intranet collaboratif, fédérant ses filiales locales. Le choix a démontré qu’une fédération SAML peut gérer efficacement des dizaines de systèmes hétérogènes tout en répondant aux exigences de conformité interne.
OAuth 2.0 : le framework de délégation d’accès
OAuth 2.0 n’est pas un protocole d’authentification, mais un mécanisme de délégation d’accès. Il permet à une application (client) d’obtenir un access token auprès d’un IdP pour invoquer une API au nom d’un utilisateur ou d’un service.
Les rôles fondamentaux sont le Resource Owner (utilisateur ou service), le Client (application consommatrice), l’Authorization Server (IdP) et le Resource Server (API). Les flows (authorization code, implicit, client credentials) s’adaptent à divers scénarios (web, mobile, machine-to-machine).
Bien implémenté, OAuth 2.0 autorise une granularité fine (scopes, audiences) et limite la durée de vie des tokens. Mal paramétré, il peut devenir une faille critique (tokens trop longs, scopes trop larges, redirections vulnérables…).
OpenID Connect (OIDC) : l’identité moderne basée sur OAuth
OIDC se superpose à OAuth 2.0 pour apporter une couche d’authentification. Il définit un ID token JWT contenant des claims d’identité (sub, email, name…) et un endpoint userinfo pour enrichir ces données.
Ce standard allie la légèreté du JSON/JWT à la sécurité d’OAuth 2.0. Il facilite l’intégration dans les applications mobiles et web modernes, tout en supportant la découverte automatique (well-known), la gestion des clés (JWK) et les flux hybrides.
Pour les environnements API-first et microservices, OIDC représente le choix de prédilection : simplicité, compatibilité avec les SDK existants, flexibilité des flows et support natif des JSON Web Tokens.
Edana : partenaire digital stratégique en Suisse
Nous accompagnons les entreprises et les organisations dans leur transformation digitale
Cas d’usage et contextes d’implémentation
Les usages diffèrent selon que l’on cible un intranet B2E, un portail B2B ou une application grand public B2C. Chaque contexte impose des exigences particulières en termes de protocoles, de sécurité et d’expérience utilisateur.
SSO interne en contexte B2E
Dans un scénario B2E, les collaborateurs accèdent à un ensemble d’applications métiers (ERP, CRM, outils collaboratifs) derrière un portail unique. Le SSO améliore l’adoption et simplifie la gestion des accès.
Le protocole SAML reste souvent privilégié pour sa maturité et son support étendu par les suites logicielles d’entreprise. OIDC gagne néanmoins du terrain pour les outils cloud natifs et les applications mobiles internes.
La complexité réside dans l’orchestration des sessions et la synchronisation des annuaires (LDAP, Active Directory). Une bonne intégration garantit une expérience fluide et une réversibilité en cas de migration d’annuaire.
Login social et mobile pour le B2C
Pour un portail grand public, le login social (Google, Facebook) couplé à OAuth 2.0/OIDC permet de simplifier l’enregistrement et l’authentification. Il réduit la barrière à l’entrée et délègue la gestion des identités à des fournisseurs de confiance.
Les applications mobiles exploitent souvent le flow authorization code with PKCE pour sécuriser les tokens sans exposer de secrets. Les ID tokens OIDC fournissent les informations d’identité de base pour personnaliser l’expérience.
Il est essentiel de gérer correctement les consentements, la révocation des tokens et la durée de vie des sessions pour respecter les obligations RGPD et garantir la confiance des utilisateurs.
Exemple : une organisation de santé suisse a déployé un portail patient mobile avec authentification OIDC et login social. Ce projet a démontré que PKCE et OIDC peuvent offrir simplicité et sécurité, tout en respectant la confidentialité réglementaire.
APIs tierces et microservices en B2B
Les échanges inter-entreprises passent de plus en plus par des APIs exposées à des partenaires. OAuth 2.0 en client credentials flow est le standard pour sécuriser ces appels machine-to-machine.
OIDC peut compléter OAuth pour identifier les services ou les utilisateurs finaux, notamment dans des chaînes de microservices où chaque composant valide un JWT pour authentifier et autoriser l’opération.
Un bon design API-first inclut la gestion du cycle de vie des tokens, l’implémentation de scopes précis et la mise en place d’un token introspection endpoint pour révoquer ou vérifier la validité des tokens.
Exemple : un retailer suisse a sécurisé ses échanges entre son ERP et la plateforme de gestion logistique avec OAuth 2.0. Cette approche a démontré l’efficacité d’un schéma client credentials pour des volumes de requêtes élevés et une intégration aisée dans un écosystème microservices.
Choisir et combiner les bons standards dans votre architecture
Le choix d’un protocole ne se fait pas isolément : il doit s’inscrire dans une architecture globale, en tenant compte des besoins de fédération, de la diversité des applications et des contraintes de sécurité.
Critères de sélection selon le contexte
Pour des applications web internes, SAML ou OIDC avec SSO sont adaptés. Les exigences de conformité et la maturité des outils peuvent orienter vers SAML dans les grands groupes, tandis que OIDC est privilégié pour des services cloud natifs.
Approche combinée et progressive
Il est fréquent de démarrer avec SAML pour un intranet, puis d’ajouter OIDC pour les nouvelles applications cloud. Une gateway d’API ou un proxy d’identité peut orchestrer plusieurs standards et unifier la couche d’accès.
Pièges à éviter et bonnes pratiques
Ne pas limiter les scopes OAuth à “openid” ou “profile” trop généraux ; privilégier des scopes métier définis pour chaque API. Éviter les tokens à durée de vie excessive et implémenter un mécanisme de rotation des clés (JWK).
Ne pas négliger l’audit des flux de redirection et des paramètres d’URL. Un paramètre mal validé peut ouvrir la porte à des attaques de type open redirect ou CSRF.
Enfin, documenter chaque composant (IdP, SP, clients OAuth) et versionner les configurations. Cela facilite la maintenance évolutive et garantit la traçabilité en cas d’incident de sécurité.
Transformer votre gestion d’identité en avantage stratégique
La maîtrise des protocoles d’authentification et d’autorisation permet de construire des écosystèmes numériques agiles, sécurisés et évolutifs. En combinant SSO, SAML, OAuth 2.0 et OIDC selon les cas d’usage, les organisations bénéficient d’une expérience utilisateur fluide et d’une gouvernance claire.
L’expertise d’une équipe dédiée peut accompagner l’audit des besoins, le choix des standards et l’intégration progressive pour éviter les failles et la dette technique. Un design contextualisé, basé sur l’open source et une architecture modulaire, garantit une solution pérenne et sans vendor lock-in.
