OpenID Connect

OpenID Connect : Couche d’identité posée sur OAuth 2.0, qui ajoute la vérification de l’identité à la simple délégation d’accès.

Le mot appartient à la famille « Sécurité » du lexique. Cette page dit ce qu’il recouvre, comment il se formule dans un cahier des charges, et ce qu’il vaut mieux ne pas écrire.

Ce que recouvre OpenID Connect, concrètement

OpenID Connect figure dans les référentiels utilisés par les auditeurs. Un client grand compte le vérifiera avant de signer, un prestataire sérieux l’a déjà prévu.

Le sujet mérite trois minutes d’attention au cadrage. C’est le seul moment du projet où il ne coûte rien à traiter.

Ce que ça devient dans un cahier des charges

Écrire « OpenID Connect » dans un cahier des charges engage un travail réel, pas une case à cocher : configuration, code, procédure, et preuve à produire.

À écrire noir sur blanc, dans le chapitre qui correspond :

• Les modalités d’authentification, second facteur compris s’il est requis.
• Le stockage des secrets, côté application comme côté serveur.
• La gestion des accès de production, et leur revue périodique.
• Le test de restauration des sauvegardes, réellement exécuté au moins une fois.

Reste à désigner qui écrit cette ligne et qui la valide. Sans nom en face, la rubrique se remplit la veille de la signature, avec les mots du prestataire.

Le modèle de cahier des charges du guide reprend ces rubriques dans l’ordre attendu par une agence, et la grille de lecture des devis montre à quoi ressemble un chiffrage comparable.

Vérifier plutôt que croire

OpenID Connect se recette avant la mise en ligne, puis se revérifie après les corrections. Un correctif non retesté n’est pas un correctif.

• Demander le rapport d’audit complet, pas la seule page de synthèse.
• Observer le comportement de l’application avec un jeton expiré.
• Vérifier que les contrôles d’accès sont bien refaits côté serveur.

Chacun de ces contrôles prend quelques minutes. Les découvrir après la mise en ligne prend des jours.

Les pièges à éviter

Ces erreurs ne viennent presque jamais d’un manque de compétence, mais d’un point qui n’a été écrit nulle part.

• Traiter la sécurité en fin de projet, quand tout est déjà recetté.
• Stocker un secret dans le code de l’application, où il est lisible par qui veut le lire.
• Commander un audit sans budgéter les corrections qu’il va produire.
• Laisser les accès de production ouverts à d’anciens intervenants.
• Ne relier le sujet à aucun critère de recette : ce qui ne se vérifie pas ne se livre pas.

Termes liés

Les entrées du glossaire déjà publiées sur des sujets voisins :

• ISO 27001
• Départ d’un collaborateur
• Appareil perdu ou volé
• Divulgation responsable
• Effacement à distance

Questions fréquentes

Que signifie « OpenID Connect » ?

Couche d’identité posée sur OAuth 2.0, qui ajoute la vérification de l’identité à la simple délégation d’accès. Cette définition suffit pour une discussion de cadrage. Pour un contrat, il faut y ajouter ce que le terme recouvre exactement sur votre application.

À quel moment traiter le sujet ?

Dès la conception, puis en contrôle avant la mise en ligne. Une faille corrigée sur plan coûte une discussion ; la même faille corrigée après le lancement coûte un correctif, une republication et parfois une notification.

Comment savoir si le budget annoncé est cohérent ?

En comparant le périmètre écrit aux fourchettes constatées en France, détaillées poste par poste sur le guide des prix. Un chiffre isolé ne veut rien dire sans le périmètre qui va avec.

Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.