Préambule
J'admets : j'ai un penchant, non pas pour la bière (quoique) mais pour les standards, protocoles et autres APIs, ouverts dans la mesure du possible.
Il reste toujours préférable de respecter les standards qui sont établis par des instances du type W3C pour ce qui concerne le Web, IETF pour tout protocole lié à Internet (TCP/IP, SMTP, ...) sous forme de RFC, ou encore les standards de fait : développés par une société qui l'a libérée afin qu'il soit adopté par la suite par le plus grand nombre, souvent sous forme d'une fondation (qui regroupe un consortium de sociétés / d'organismes).
Je me suis intéressé dernièrement à OpenID, standard ouvert d'authentification, Wikipédia définit très bien ce protocole et standard ouvert :
OpenID est un système d’authentification décentralisé qui permet l’authentification unique, ainsi que le partage d’attributs. Il permet à un utilisateur de s’authentifier auprès de plusieurs sites (devant prendre en charge cette technologie) sans avoir à retenir un identifiant pour chacun d’eux mais en utilisant à chaque fois un unique identifiant OpenID
La fondation OpenID regroupe les grands acteurs du Web (Google, MS, FB, ...une belle liste), avec l'objectif que ce standard soit utilisé et déployé vers le plus grand nombre de sites.
OpenID prend également part à OpenStack, pile de standards pour le Web (OpenID, OAuth, OpenSocial ou sur Google code OpenSocial, XRDS-Simple : utilisé par OpenID ou OAuth, pour la découverte dynamique de services, PortableContacts), qui se schématise par l'image suivante :
La base d'OpenID : l'URL
l'adresse Web du fournisseur OpenID
Dans sa version 1.x, le protocole est basé sur une URL qui représente l'identité de l'utilisateur. Parmi les fournisseurs OpenID, nous trouvons parmi le plus connu MyOpenID, mais on pourrait citer également ClaimID, MyID.is, Ziki, Verisign.
On voit souvent le champ suivant avec le logo représentatif d'OpenID qui spécifie que le site prend en charge ce standard :
L'avantage d'une URL est qu'elle peut être utilisée aussi comme une carte d'identité : l'adresse OpenID, en plus d'être une clé d'authentification, sert de carte de visite Web, comme les suivantes qui représentent mon identité ou du moins ma carte de visite :
- http://zorky.myopenid.com : en plus d'informations telles qu'email, localisation, MyOpenID fournit également une vCard pour importer directement ses informations sous Outlook par exemple,
- http://www.google.com/profiles/zorky00 Google profiles, sous sa forme URL : permet une personnalisation de ses différents réseaux sociaux ou sites/blogs, ainsi que sa localisation, photos Flickr, mini-CV,
- http://www.ziki.com/zorky : le plus abouti avec Google mais ne semble pas fonctionner sur tous les sites,
- http://zorky.pip.verisignlabs.com : Verisign offre une grande marge de personnalisation de sa carte de visite OpenID, et de télécharger sa CardSpace (uniquement sous Windows). Verisign fournit une extension Firefox pour remplir et s'authentifier automatiquement par son URL,
- http://myid.is/olivier.duval.id : simple, certifie vos sites/blogs,
- http://claimid.com/zorky
la délégation d'URL
Lorsque l'on a un domaine Internet et un ou plusieurs sites, ces derniers servent aussi de carte de visite. OpenID autorise la délégation d'authentification à l'aide d'un jeu de balises link dans une page HTML.
Par exemple mon site portail http://olivier-duval.info contient les balises suivantes qui font référence à mon compte MyOpenID (zorky.myopenid.com) :
<link rel="openid.server" href="https://www.myopenid.com/server " /> <link rel="openid.delegate" href="http://zorky.myopenid.com " /> <link rel="openid2.provider" href="http://www.myopenid.com/server " /> <link rel="openid2.local_id" href="http://zorky.myopenid.com " />
ces balises dans la section head de la page d'accueil auront pour effet que je puisse utiliser olivier-duval.info comme adresse / identifiant OpenID sur les sites qui proposent l'authentification OpenID (principale ou en alternative), pratique : j'expose ma carte de visite en même temps que la possibilité de m'authentifier.
le challenge : améliorer l'expérience utilisateur OpenID (OpenID UX)
OpenID 2.0 et la fonctionnalité Directed identity
OpenID 2.0 a apporté notamment les nouveautés suivantes (on pourra lire cet article sur la v2.0) :
- directed identity
- attribute exchange extension (AX)
La 1ère était pour Google et Yahoo, la condition au passage à OpenID, la killer-feature et cela en est bien une.
Avec OpenID 1.1, l'utilisateur s'identifie grâce à une URL, où l'identifiant utilisateur est embarqué dans cette dernière, comme nous l'avons vu précédemment (dans mon cas : http://olivier-duval.info ou http://zorky.myopenid.com). Pour le commun des mortels, cette approche peut paraitre perturbante : saisie d'une URL puis une authentification par login et mot de passe.
Avec OpenID 2.0, on ne précise plus l'URL utilisateur,seul l'adresse du provider suffit (en langage technique l'OpenID end-point) : l'application fournit l'URL du provider (le paramètre openid.claimed_id envoyé au fournisseur contiendra alors la valeur http://specs.openid.net/auth/2.0/identifier_select au lieu de l'URL OpenID utilisateur) qui se chargera d'authentifier l'utilisateur (par login/mot de passe), le provider répondra à l'application cliente en lui fournissant l'URL utilisateur.
Concrétement, cela permet de développement des widgets contenant des icônes cliquables (RPX l'a compris depuis longtemps), que nous voyons de plus en plus sur les sites : cela améliore l'expérience utilisateur (OpenID UX), par une approche plus simple sous forme d'un clic sur une image plutôt qu'une saisie d'URL.
On pourra alors trouver ce type de bannières où d'un clic l'utilisateur est redirigé vers le fournisseur de son choix :
des librairies jQuery commencent à naitre : sur jVance.com, OpenID-selector, ou en développer une spécifique pour intégrer Orange.
Quels fournisseurs ?
Tous les fournisseurs OpenID n'implémentent pas tous OpenID 2.0 et la fonction directed identity. Parmi les fournisseurs qui ont adopté la spécification OpenID 2.0 (avec le directed identity) et leur end-point (URL) d'accès, sont nominés (tous ont été testés) :
- Google : https://www.google.com/accounts/o8/id (par l'utilisation d'une requête XRDS pour l'obtention du end-point réelle pour la redirection OpenID, cf. l'API Google OpenID),
- Yahoo : http://me.yahoo.com - option : peut nécessiter la mise en place d'un fichier XRDS pour retirer le message d'avertissement sur le site demandeur (non "vérifié" par défaut, cf. cette intéressante question),
- Flickr (appartient à Yahoo) : http://www.flickr.com,
- Orange : http://openid.orange.fr (http://orange.fr devrait également fonctionner),
- MyOpenID : http://www.myopenid.com,
- Verisign : https://pip.verisignlabs.com,
- MySpace : http://www.myspace.com
Sur le blog de JanRain (RPX), il est intéressant de constater que sur 173 000 sites qui utilisent leur widget, 37,4 % des utilisateurs préférent Google (source)
L'avantage ?
Personnellement je suis constamment connecté sur mon compte Google, pour lire mes mails, mes flux, mon calendrier, voire éditer des fichiers. Lorsque je vais sur un site qui accepte Google comme authentification OpenID, il suffit d'un clic pour y accéder car je suis déjà connecté sur Google, doublement pratique :
je ne retiens et ne conserve qu'un login (mon email) / mot de passe, ma connexion est facilitée et rapide car j'ai un usage important des services Google (cela pourrait en être autant avec Yahoo, MySpace ou Orange).
Concernant Google, une partie de l'URL renvoyée à l'application cliente (RP : Relying Party) est hashée sur le domaine appelant et diffère donc selon l'application qui effectue la demande d'authentification.
Par exemple, si je teste mon authentification Google sur mon essai RPX, j'obtiens comme identifiant OpenID www.google.com/accounts/o8/id?id=XXXXwkvXsnU5vv4V7ECA7MVcqx4cz1GdQJ-yUA , par Stackoverflow, un autre identifiant www.google.com/accounts/o8/id?id=XXXXkyhuj2bdptserwktuerhwtotmxwtztguo, différent donc. Cela peut être gênant d'unifier le "login" utilisateur Google pour plusieurs applications Web (ie : sur des domaines différents). Google calcule le hash contenu dans l'URL retournée selon le paramètre openid.realm (qui contient le domaine / hôte RP qui effectue la requête OpenID), c'est très bien expliqué à la section Request authentication response.
internautes : quelle utilisation ? Directed Identity ou par URL ?
Lorsque le site ne propose pas une authentification Google, j'utilise mon adresse http://olivier-duval.info, mais de plus en plus de sites proposent Google ou Yahoo comme authentification principale. On pourra citer StackOverflow (et ses avatars : http://serverfault.com http://superuser.com , ça manque de SSO dans ce cas d'ailleurs), Diigo, UserVoices, Plaxo, FriendFeed - soit ils proposent 1 seule identité, soit N identités alternatives (1 compte local + n comptes OpenID du type Google, Yahoo, ...) : on nous donne la liberté de choix, et j'aime cette démarche.
sites qui gèrent des comptes: compte local ou alternatives avec OpenID ?
Des sites ont choisi de n'avoir que des comptes externes (par exemple Stackoverflow), tout en proposant un 2è compte OpenID pour se connecter (si le 1er fournisseur venait à tomber par exemple).
D'autres, Diigo (possibilité d'autant de comptes supplémentaires que l'on souhaite), BaseCamp (1 seul OpenID), Plaxo, Facebook (autant que l'on souhaite), ...ont choisi OpenID comme compte alternatif au compte local créé lors de son inscription.
Le 1er est le plus risqué, même si il est calculé, il faut au moins proposer la possibilité d'enregistrer un 2è compte OpenID, car nous restons tributaires du fournisseur OpenID (Google, Yahoo, ...), le compte local, lui, fonctionnera (presque) toujours.
aide à la pré-inscription
Un autre usage d'OpenID peut concerner la pré-inscription. Lors de la connexion avec son compte Google, le site RP / demandeur peut solliciter des champs de retour, du type l'email, le nom, etc. Cet échange est décrit dans la spécification OpenID SR qui inclut une liste finie de champs. Dans ce cas là, on pourrait pré-remplir quelques informations sur le futur abonné au site. Un billet sur le sujet (par FB Connect ou Twitter mais l'idée reste la même).
On pourrait aller bien plus loin dans l'échange d'attributs entre un site client et un provider, en se basant sur OpenID 2.0 et la spécification OpenID Attribute Exchange (cf. ce billet sur le sujet).
et les autres fournisseurs : Facebook, Microsoft (LiveID) ?
Facebook a pris la voie d'un protocole propriétaire pour l'authentification : Facebook Connect. Malheureusement je dirais, car cela ne couterait pas très cher de passer à OpenID en tant que fournisseur (OpenID Provider / OP), et tellement appréciable. J'espère que Facebook deviendra un jour OP avec la fonctionnalité directed identity, cela éviterait d'implémenter un protocole supplémentaire.
En revanche, FB (ayant rejoint la fondation OpenID) autorise le RP (Relying Party) en ... mode automatique : il suffit de lier son compte Facebook avec ses différents fournisseurs OpenID, et dès que vous accéderez à la page d'accueil http://www.facebook.com , si vous êtes déjà connectés (sur Google par exemple) vous serez automatiquement authentifier à Facebook, pas mal pour le coup, riche idée j'ai trouvé. FB stocke tout ce p'tit monde dans un cookie (openid_p), cela vaut donc uniquement sur le poste courant, à moins de s'être au moins connecté 1 fois sur FB sur le poste afin qu'il puisse positionner le cookie.
Pour cela, il suffit d'aller dans Paramètres > Compte > Comptes liés. L'idée est séduisante, sans compter l'ergonomie de sélection du fournisseur que je trouve particulièrement réussie (pour la reprendre à mon compte d'ailleurs) :
Microsoft / LiveID
Microsoft qui a adhéré à la fondation, a entrepris (en Community Tech Preview) le passage des comptes LiveID en OpenID. Aux dernières nouvelles, ce n'était pas actif sur les vrais comptes LiveID, mais toujours en test (cf. le site de test, pas de nouvelle, bonne nouvelle ? 500 millions de comptes sont concernés, il serait dommage de ne pas en profiter un jour).
Mais selon la newsletter de la fondation, il y a un bon espoir : cf. la partie OP Progress : "Microsoft committed to becoming an OpenID Provider in 2010"
librairies
- Java : open4java
- PHP et Ruby édités par RPX
- plus ici
- et je finirais par .NET : l'excellente librairie DNOA (il y a également ExtremeSwank mais déconseillé car la version RP est compromise et n'est plus maintenue) qui implémente totalement les spécifications d'OpenID v2.0, contrairement à ces concurrents :
- le site officiel DotNetOpenAuth : OpenID 1x et 2.0, RP et provider, AX, implémente la fonctionnalité directed identity
- les sources
- le groupe : pour avoir posé quelques questions, le principal contributeur (travaille chez MS du côté de la XBox ;)) répond assez rapidement
- de nombreux projets exemples, soit en ASP.NET MVC, soit en ASP.NET WebForms
- DNOA de son petit nom, implémente également le protocole OAuth, API standard d'autorisations, très utilisée sous Twitter (permet d'utiliser une API par le biais de son compte mais sans laisser ses logins / mot de passe au site tiers utilisateur de l'API), et prend en compte InfoCard
- expérience utilisateur avec jQuery : http://openidux.dotnetopenauth.net
N'hésitez pas pour voter des évolutions sur l'UserVoice du projet (les implémentations de FB Connect ou de MS LiveID seraient un très bon début).
OpenID : la solution miracle à l'authentification ?
Bien entendu que non. A défaut d'être parfait, cela a le mérite d'essayer de sortir un standard qui répond à un besoin classique et récurrent sur Internet : l'inscription et l'utilisation de logins et mot de passe sur des applications ou services. Personnellement, je dois être inscrit à environ 300 sites, avec pour chacun des règles différents pour le choix du login (email, login, déjà pris, ...), mot de passe (trop court, pas assez compliqué, ...) et j'en passe.
L'essayer, c'est l'adopter, d'autant plus qu'avec la fonctionnalité directed identity, soutenue par Google, Yahoo, Orange & co (et bientôt AOL en 2010), l'expérience utilisateur devient bien plus simple.