Julien Carnelos Blog – Archives

Pour faire suite à mon premier article qui servait d’introduction, je souhaitais revenir sur la notion de centralisation du serveur d’authentification.
OpenId étant un protocole ouvert, quiconque peut implémenter le mécanisme serveur d’authentification sur son domaine. J’avais cité en exemple verisignmais il en existe beaucoup d’autres comme http://getopenid.com/.

Cette dépendance envers un serveur est forte et imaginons qu’un jour, un provider comme getopenid décide de faire payer son accès, nous nous retrouvons lié sans autre choix que d’accepter ou perdre son accès.

Et bien la solution à ce problème s’appele la délégation.

Si vous avez bien suivi, pour le moment notre identité openid est une url. Par exemple pour mon id verisign, c’est juliencarnelos.pip.verisignlabs.com.

Cette url n’est pas seulement une clé unique comme peut l’être un identifiant nom ou un email, car elle permet également de certifier la validité de l’id.
Ainsi, si je m’authentifie chez Ebay (en théorie, car Ebay ne fait pas encore d’openid 😉 ), Ebay va interroger le nom de domaine « verisignlabs.com » pour avoir les infos me concernant.

Nous en arrivons donc au principe de délégation. Mon ID étant une URL accessible, je vais pouvoir utiliser n’importe quelle url qui contiendra une délégation vers un vrai provider d’openid.

Concrètement, grâce à mon nouveau nom de domaine, je vais pouvoir utiliser comme Open ID «  ». Il me suffira de modifier le fichier index.php et de rajouter à l’intérieur du head les 2 lignes de délégation :

   <link rel="openid.server" href="http://pip.verisignlabs.com/server" />
   <link rel="openid.delegate" href="http://juliencarnelos.pip.verisignlabs.com" />

De ce fait la dépendance sera uniquement vers mon domaine (qui m’appartient). Ainsi je peux changer de fournisseur quand je le décide en changeant simplement ces deux lignes…