Résumé

  • Le plan T3 2026 de RIPE NCC annonce le passage du site RIPE Database d’un cookie sécurisé commun à une session appelée OIDC 2.0, alors que la norme d’identité examinée s’appelle OpenID Connect 1.0 et repose sur OAuth 2.0.
  • L’identité fournie par OIDC ne vaut pas autorisation générale. La documentation de RIPE Database conserve la décision d’agir dans les relations entre compte SSO, justificatif et objet mntner.
  • Une recette publique limitée doit relier profil normatif, durée de session, déconnexion, extinction de l’ancien cookie, contrôle mntner, sort des clés API, essais de refus, retour arrière et autorité de clôture.

Deux registres derrière le même écran

L’utilisateur voit une seule séquence : il choisit « se connecter », passe par RIPE NCC Access, revient dans l’application et soumet une modification. Pour l’exploitant, cette séquence contient pourtant deux registres. Le premier dit quelle identité a été authentifiée et pendant combien de temps l’application accepte sa session. Le second dit quel mntner protège l’objet et si cette identité possède le justificatif requis pour l’opération demandée.

Le plan trimestriel de RIPE Database, mis à jour le 11 juin 2026, décrit le premier registre. Son deuxième chantier veut remplacer l’authentification interactive fondée sur un cookie sécurisé à portée générale par une session OIDC 2.0. Le statut reste « en cours ». La finalité affichée est d’améliorer la sécurité des requêtes authentifiées. C’est une direction raisonnable : une fédération d’identité bien délimitée peut centraliser les exigences du compte, réduire les conventions propres à une application et rendre l’émetteur comme le destinataire plus explicites.

Le nom retenu mérite néanmoins une précision avant la clôture. OpenID Connect Core est une norme 1.0 construite au-dessus d’OAuth 2.0. La gestion de session et les différentes formes de déconnexion ont leurs propres spécifications 1.0. Dans les documents publics consultés, il n’existe pas de norme finale portant le nom OIDC 2.0. L’expression du plan peut être un raccourci interne pour OpenID Connect sur OAuth 2.0, une simple coquille ou le nom d’un profil maison. Aucun élément public ne permet de trancher.

Une ambiguïté de version n’est pas seulement éditoriale. Elle détermine la liste des contrôles qu’une équipe de recette croit devoir exécuter. Il faut savoir quel flux est utilisé, quel émetteur est approuvé, quelle identité de client représente l’application, quels paramètres protègent le retour, quelles revendications sont acceptées, à quel moment une session locale naît et comment elle meurt. Un intitulé composite ne répond à aucune de ces questions.

Changer de protocole ne supprime pas l’état local

La formulation « du cookie vers une session OIDC » peut laisser croire que le cookie disparaît avec l’ancien mécanisme. Une application web fédérée garde souvent un état local après la réponse du fournisseur d’identité. Cet état peut encore être présenté au navigateur par un cookie, tandis que RIPE NCC Access conserve une autre session de son côté. Les deux horloges n’ont pas nécessairement la même durée et les deux déconnexions ne sont pas automatiquement équivalentes.

La spécification OpenID Connect Session Management traite justement de l’état de connexion chez le fournisseur et chez la partie utilisatrice. La spécification RP-Initiated Logout décrit, séparément, la demande par laquelle l’application sollicite la fin de la session auprès du fournisseur. Ce découpage normatif indique une chose simple : la réception ne doit pas se limiter à constater qu’un retour OIDC aboutit. Elle doit démontrer ce qui arrive avant, pendant et après l’établissement de la session locale.

Pendant une bascule, quatre horloges peuvent coexister. Il y a l’authentification chez le fournisseur, la validité d’un jeton, la session locale de RIPE Database et la lecture de l’autorité mntner. Une déconnexion locale, une déconnexion du fournisseur, la désactivation d’un compte, la suppression d’une association de mainteneur et l’expiration d’une clé API sont des événements différents. Ils peuvent converger vers le même résultat sans emprunter le même chemin.

Prenons une situation neutre. L’ancien cookie reste accepté vingt minutes après l’activation du nouveau chemin afin de ne pas interrompre une édition en cours. Cette coexistence peut être un choix sûr. Mais elle crée deux dates de fin, et la preuve doit nommer laquelle s’applique à une session déjà ouverte. À l’inverse, invalider tout le monde au moment de la bascule réduit l’ambiguïté mais augmente le risque d’interrompre des opérations légitimes. L’essentiel n’est pas d’imposer l’une de ces politiques ; c’est de rendre la politique choisie vérifiable.

Le mntner reste le point de décision

La documentation de RIPE Database distingue expressément authentification, autorisation et justificatif. L’authentification répond à la question de l’identité. L’autorisation porte sur le droit d’agir. Le justificatif donne une raison de croire que ce droit peut être exercé. Cette distinction est particulièrement importante dans une base où un même compte peut être associé à plusieurs mainteneurs et où des objets différents sont protégés par des relations différentes.

L’objet mntner contient les références aux moyens d’autorisation, notamment les comptes SSO et certaines clés cryptographiques. Une session OIDC peut acheminer une identité attestée jusqu’à l’application. Elle ne transforme pas cette identité en administrateur universel. Au moment de la mise à jour, le service doit encore résoudre le mntner qui protège l’objet, comparer les justificatifs applicables et refuser l’opération si la relation nécessaire manque.

Les règles des clés API rendent ce mécanisme visible. Une clé appartient à un compte RIPE NCC Access. Avant de l’utiliser pour une mise à jour, le compte doit être lié à un mainteneur par un attribut auth: SSO. L’éditeur peut limiter la clé à un mainteneur précis. La clé a aussi une date d’expiration, un historique de dernière utilisation et une fonction de révocation. Ces propriétés maîtrisent le justificatif ; elles ne remplacent pas l’autorité de l’objet.

RIPE-843 ajoute les obligations du compte : authentification à deux facteurs, identifiant destiné à une seule personne, durée maximale d’un an pour les clés API. Le document indique également qu’une clé est désactivée lorsque le compte SSO associé l’est ou lorsque l’utilisateur cesse d’être mainteneur dans la base applicative concernée. La chaîne est donc volontairement composée. Un changement dans le compte doit atteindre le justificatif, puis l’opération doit encore satisfaire la protection du mntner.

Ce que prouve le code public de 2025

Le dépôt public RIPE-NCC/whois consigne la prise en charge d’OAuth 2.0 dans la version 1.117. La demande de fusion 1688, intitulée Support oauth2, a été fusionnée le 3 mars 2025. Parmi ses modifications figure une longue suite d’essais d’intégration pour les jetons Bearer.

Deux essais négatifs sont particulièrement instructifs. L’un présente un jeton associé à un mainteneur différent de celui qui protège l’objet ; l’autre combine le même mainteneur avec une identité SSO inadéquate. Dans les deux cas, le résultat attendu est un refus et l’objet ne doit pas être modifié. Le test ne s’arrête donc pas à un code d’erreur : il vérifie l’absence de changement d’état.

Cette preuve de code renforce la thèse sans fermer le projet de 2026. Elle montre qu’une authentification par jeton et une autorité mntner sont deux décisions. Elle ne montre pas que la nouvelle session interactive est déployée, car le composant, la date et la surface diffèrent. Confondre le support Bearer de 2025 avec la session web en cours de 2026 reviendrait à utiliser un reçu voisin pour solder une autre livraison.

La recette à publier

Une fiche de bascule peut rester courte si elle conserve les bons raccords. Côté identité, elle devrait nommer OpenID Connect Core 1.0, la base OAuth 2.0 et les profils complémentaires réellement retenus. Elle devrait indiquer, sans secrets, l’émetteur, le rôle client de l’application, la classe de flux, les durées absolue et d’inactivité, la stratégie de rafraîchissement, le type de déconnexion et la fin d’acceptation de l’ancien cookie.

Côté autorité, la même fiche devrait préciser quand l’association SSO-mntner est lue, comment une suppression atteint une session ouverte, si les clés API suivent un autre calendrier, quelles familles d’objets et d’opérations ont été testées, quels cas permis ont réussi et quels cas interdits ont été refusés sans changement. Une fenêtre d’observation, un seuil de retour arrière et la fonction qui accepte la clôture complètent le dispositif.

Aucune valeur de cookie, de jeton ou de clé n’a besoin d’être publiée. Les courriels des comptes et les secrets des mainteneurs doivent rester privés. Des identifiants anonymes de cas, la classe de relation attendue, le verdict et l’empreinte du résultat suffisent à rendre l’acceptation reproductible. En cas de correction, une nouvelle version s’ajoute à l’ancienne au lieu d’effacer la preuve initiale.

Limites de la conclusion

Les sources ne donnent ni émetteur, ni client, ni flux, ni revendications, ni durées, ni attributs du cookie, ni méthode de déconnexion pour ce chantier. Elles ne fixent pas sa date de production ni sa période de compatibilité. Elles ne prouvent pas que l’expression OIDC 2.0 est fautive plutôt qu’interne. Elles ne montrent aucune session active périmée, aucun compte compromis, aucun mauvais rattachement, aucune mise à jour non autorisée, aucune perte de données et aucune panne.

La conclusion défend donc le projet tout en bornant sa clôture. RIPE NCC peut moderniser l’authentification et préserver exactement la même règle d’autorisation. Pour le démontrer, il faut publier le raccord entre la vraie norme, le cycle de la session et les essais positifs et négatifs du mntner. Une connexion moderne est une amélioration ; un reçu de bascule en fait un contrôle durable.

Sources