Résumé

Google tenait le calendrier, le site tenait le registre

Le communiqué de février 2014 célébrait l'adoption d'OpenID Connect et fixait dans le même mouvement une date de sortie pour OpenID 2.0 : le 20 avril 2015. Google voulait concentrer ses services de connexion fédérée sur le nouveau protocole. Les développeurs disposaient de plus d'un an pour adapter leurs applications. Leur marge de temps ne changeait pas le rapport de force : le fournisseur d'identité pouvait fermer l'ancienne entrée, tandis que chaque site dépendant de cette entrée devait préparer la suite.

Dans la base d'un tel site, l'ancien identifiant avait déjà une histoire. Il pouvait être la clé d'un compte contenant un abonnement, des travaux enregistrés, des achats ou des droits. Avec OpenID 2.0, le site recevait un identifiant revendiqué et vérifié. OpenID Connect décrit l'utilisateur par un couple : l'émetteur du nouveau jeton et le sujet qu'il désigne. Même personne possible, clé différente. Le nouveau bouton peut fonctionner parfaitement et créer malgré tout un deuxième compte vide. Une association hâtive peut attribuer le vieux compte à une autre personne.

Le rappel publié par Google le 20 mars 2015 nommait la sanction opérationnelle. OpenID 2.0 et plusieurs anciens protocoles cesseraient de fonctionner le 20 avril. Une application restée sur ces mécanismes risquait une interruption de sa liaison avec Google, éventuellement jusque dans la connexion des utilisateurs, jusqu'à sa migration. Le fournisseur annonçait une panne possible et datée ; il ne publiait pas un recensement des pannes déjà subies. Son pouvoir portait sur le service d'authentification qu'il exploitait.

Une norme achevée juste avant la fermeture

La fondation OpenID a enregistré son vote final le 16 avril 2015 : 28 voix favorables, aucune contre, quatre abstentions. Il restait quatre jours avant la date de Google. Ce délai serré concernait l'approbation du texte final, pas le début du travail. La date d'arrêt était publique depuis février 2014, et l'annexe de la spécification compare ses règles à un guide de migration Google daté de juin 2014. Le vote achevait une méthode commune pour résoudre un problème plus précis que le remplacement d'une interface : donner au bon titulaire l'accès au compte déjà présent.

La spécification part de deux formats d'identité. L'ancien est l'identifiant revendiqué et vérifié d'OpenID 2.0. Le nouveau est le couple émetteur-sujet d'OpenID Connect. Le site demande les deux en ajoutant la portée openid2 à la requête d'authentification. Si le fournisseur connaît un ancien identifiant associé à cet utilisateur, il le place dans le jeton d'identité sous le nom openid2_id. Le site vérifie ce jeton conformément à OpenID Connect. Il reste alors une question que la signature du nouveau jeton, à elle seule, ne résout pas : cet émetteur est-il habilité à parler pour l'ancien identifiant ?

Le texte final place un contrôle à cet endroit. Dans un cas restreint, la même autorité pour les anciens et nouveaux points d'entrée peut suffire. Dans les autres cas, le site interroge l'ancienne URL avec Accept: application/json, recueille le champ iss, puis le compare exactement à l'émetteur du jeton. Un chemin distinct existe pour les identifiants XRI. Si l'autorité ne se vérifie pas, l'ancien identifiant ne peut pas servir à joindre les comptes. Après vérification, le site peut associer le compte OpenID 2.0 existant à l'identifiant OpenID Connect. C'est la modification de son propre registre qui assure la continuité, et non une simple réussite de la connexion.

L'annexe B de la norme conserve les traces d'un désaccord de procédure avec le guide Google de juin 2014. Elle relève openid.realm dans ce guide contre openid2_realm dans la norme, puis openid_id contre openid2_id. Elle indique aussi que le guide ne comportait pas les vérifications du site demandeur et de l'autorité sur l'ancien identifiant décrites par le texte final. Cette comparaison est celle des rédacteurs de la spécification avec un guide daté ; elle ne mesure pas le comportement de chaque déploiement Google. Elle montre le travail accompli par une norme de migration lorsqu'elle refuse de confondre une assertion nouvelle avec le droit sur un vieux compte.

Les sources ne chiffrent pas les migrations achevées ni les associations erronées. Il faudrait les journaux et essais des sites pour les établir. Le partage des responsabilités est documenté : Google fixait la fin d'un protocole ; le site qui conservait le compte devait prouver à qui il le rendait.