OpenID Connect et connexions tiers
Bonne lecture et bon apprentissage ! Junior TSAFACK – 09/10/2026 Temps de lecture estimé : 10 minutes
Ce chapitre suppose une familiarité avec OAuth 2.0, déjà traité en profondeur dans le cours OAuth dédié de ce site (grant types, Authorization Code + PKCE, bonnes pratiques). OpenID Connect se construit directement par-dessus ce protocole.
OpenID Connect : OAuth 2.0 plus l’identité
Section titled “OpenID Connect : OAuth 2.0 plus l’identité”OAuth 2.0 répond à une question d’autorisation : comment une application tierce accède-t-elle à des ressources au nom d’un utilisateur, sans connaître ses identifiants ? OpenID Connect (OIDC) ajoute par-dessus une couche d’authentification : comment une application vérifie-t-elle qui est réellement l’utilisateur ?
Concrètement, l’utilisateur est redirigé vers le point de terminaison d’authentification d’un fournisseur d’identité (IdP), où il se connecte (identifiants, MFA, réseau social). Après authentification réussie, l’IdP émet un jeton d’identité (au format JWT, signé numériquement) contenant l’identifiant unique de l’utilisateur, son nom, son adresse e-mail et d’autres revendications optionnelles. OIDC permet aussi d’obtenir, séparément, des jetons d’autorisation (accès, rafraîchissement) suivant le flux OAuth 2.0 standard.
Un point souvent sous-estimé : OIDC intègre nativement la gestion du consentement utilisateur — l’utilisateur peut accorder ou révoquer, via l’interface de l’IdP, l’accès de chaque application à ses informations d’identité. L’adoption est massive : au-delà des géants du web, des organismes sectoriels entiers (la GSMA, qui réunit plus de 750 opérateurs mobiles et 400 fabricants) ont bâti leur stratégie d’infrastructure d’identité autour d’OIDC.
Les connexions tierces : trois mécanismes à distinguer
Section titled “Les connexions tierces : trois mécanismes à distinguer”| Mécanisme | Rôle |
|---|---|
| API | Règles et protocoles permettant à des applications de communiquer et d’échanger des données sans tout redévelopper. |
| Extensions d’application (plugins) | Étendent les capacités d’une application existante selon des besoins spécifiques, sans modifier son code de base. |
| Intergiciel (middleware) | Couche intermédiaire qui traduit protocoles et formats de données entre systèmes hétérogènes — un bus de services d’entreprise (ESB) intégrant CRM, ERP et systèmes historiques en est un exemple typique. |
Ces trois mécanismes permettent d’étendre des fonctionnalités et d’intégrer des services externes — mais chacun doit être évalué pour sa sécurité, sa fiabilité et sa compatibilité avant intégration, car l’organisation reste responsable en dernier ressort de la sécurité de ses informations, quel que soit le prestataire choisi.
Externaliser la gestion des identités : deux questions à poser
Section titled “Externaliser la gestion des identités : deux questions à poser”Face à la confusion fréquente du vocabulaire cloud, deux questions permettent de clarifier n’importe quelle situation d’externalisation :
- Qui emploie les administrateurs qui exécutent les tâches IAM ? — gestion « en interne » (personnel employé directement) contre « tierce partie » (accord de niveau de service avec un prestataire externe).
- Où sont physiquement hébergés les systèmes et bases de données d’authentification, d’autorisation et de comptabilité (AAA) ? — « sur site » contre « hébergé dans le cloud » (les solutions hybrides étant très courantes).
Les prestataires ne sont pas toujours précis sur le vocabulaire qu’ils emploient pour décrire leurs services — la responsabilité finale de la performance de ces services incombe toujours à la direction de l’organisation cliente, que la mise en œuvre soit interne ou externalisée.
L’identité en tant que service (IDaaS)
Section titled “L’identité en tant que service (IDaaS)”L’IDaaS est un service de gestion des identités et des accès basé sur le cloud, dans un modèle multi-tenant ou dédié. En substance, c’est un SSO basé sur le cloud, qui gère aussi le provisionnement et le déprovisionnement associés — un sujet approfondi au chapitre 4 du module suivant.
Synthèse
Section titled “Synthèse”- OpenID Connect ajoute une couche d’authentification (identité de l’utilisateur) par-dessus l’autorisation qu’offre OAuth 2.0 — les deux protocoles sont complémentaires, pas concurrents.
- API, extensions et intergiciels sont trois mécanismes distincts d’intégration tierce, chacun avec ses propres risques à évaluer avant adoption.
- Externaliser sa gestion des identités se clarifie en répondant à deux questions : qui emploie les administrateurs, et où sont hébergées les données AAA — la responsabilité finale reste toujours celle de l’organisation cliente.
Prochain chapitre
Section titled “Prochain chapitre”Junior TSAFACK – 09/10/2026