OpenID 2.0 : garder son URL, changer de fournisseur

Résumé

OpenID Authentication 2.0 distinguait l’URL que l’utilisateur revendiquait comme identifiant du nom qu’un fournisseur d’authentification lui attribuait localement. L’URL pouvait rester la même lorsque le fournisseur changeait.
Cette continuité exigeait du site qui acceptait la connexion qu’il découvre le fournisseur depuis l’URL, vérifie la réponse reçue et rattache son compte local à l’identifiant revendiqué. La spécification décrit ce mécanisme, sans mesurer sa réussite dans les sites déployés.

Le point fixe était une adresse. Dans la spécification finale OpenID Authentication 2.0, publiée le 5 décembre 2007, une personne pouvait présenter une URL comme identifiant à un site. Ce dernier n’avait pas besoin de recevoir son mot de passe. Il consultait les informations de découverte publiées à cette adresse, envoyait le navigateur vers le fournisseur d’authentification indiqué, puis contrôlait sa réponse. L’annonce de la fondation OpenID présentait ce protocole comme final avec une spécification distincte d’échange d’attributs. L’idée décisive tenait à la connexion elle-même : le nom d’une personne et le service chargé de vérifier ses secrets pouvaient appartenir à deux domaines différents.

Le texte donnait un nom à chaque rôle. Le Claimed Identifier était l’identifiant dont l’utilisateur revendiquait le contrôle. L’OP-Local Identifier était un nom interne au fournisseur, qui ne se trouvait pas nécessairement sous le contrôle de l’utilisateur. Les confondre revenait à déplacer la propriété du nom. Si un site enregistrait le nom interne comme clé du compte, un changement de fournisseur pouvait lui présenter un « nouvel » utilisateur alors que l’URL revendiquée, elle, n’avait pas bougé.

La découverte par HTML rendait l’arrangement visible. Dans la page correspondant à l’URL revendiquée, un lien rel="openid2.provider" indiquait l’adresse du fournisseur. Un second lien facultatif, rel="openid2.local_id", pouvait donner l’identifiant local de la personne chez ce fournisseur. Le serveur hébergeant l’URL revendiquée pouvait être différent de celui du fournisseur. Une personne maîtresse de sa page pouvait donc modifier le pointeur vers le service qui l’authentifiait, tout en présentant la même adresse aux sites qui la connaissaient.

Cette souplesse avait un prix pour ces sites. La spécification exigeait qu’ils vérifient qu’une réponse affirmant un identifiant provenait bien d’un fournisseur découvert pour cet identifiant. L’adresse du fournisseur et le nom local annoncés dans la réponse devaient correspondre aux données découvertes. Si le site n’avait pas encore effectué la découverte, il devait la faire à réception. Sans ce contrôle, un fournisseur quelconque pourrait prétendre parler au nom d’une URL appartenant à quelqu’un d’autre. La page de l’utilisateur indiquait le messager autorisé; le site devait regarder d’où venait le message.

Le choix de la clé dans le fichier des comptes comptait autant que la vérification réseau. OpenID recommandait d’utiliser l’identifiant revendiqué pour conserver les données locales de l’utilisateur. La compatibilité avec OpenID 1.1 rendait le risque encore plus net : une réponse ancienne ne transportait pas openid.claimed_id. Si le nom revendiqué et le nom local du fournisseur différaient, le site devait mémoriser le premier pendant la procédure, par exemple dans sa session, pour ne pas attribuer la réponse au mauvais compte.

La fondation présentait OpenID comme décentralisé : aucune autorité centrale n’avait à approuver les fournisseurs ou les sites utilisateurs, et une personne pouvait conserver son identifiant en changeant de fournisseur. C’était la propriété annoncée par le protocole. La spécification ne donne ni nombre de sites ayant bien appliqué les règles, ni taux de migrations réussies. Pour que la promesse fonctionne, il fallait garder le contrôle de l’URL, publier le bon pointeur et rencontrer des sites qui vérifiaient la découverte puis rangeaient le compte sous le bon nom.

OpenID avait ainsi déplacé la question de pouvoir. L’entreprise qui savait vérifier un mot de passe n’avait pas à posséder l’identité publique utilisée ailleurs. Mais la séparation n’était pas gratuite : l’utilisateur tenait l’adresse, le fournisseur signait l’authentification, et chaque site conservait une part décisive de l’autorité en choisissant quelle identité ouvrir. Le droit de changer de fournisseur reposait sur une suite de gestes techniques que les utilisateurs ne voyaient pas.