article.md 6.0KB
title: Différences entre identification, autorisation et authentification slug: differences-entre-identification-autorisation-et-authentification date: 2008-07-16 15:39:22 type: post vignette: images/logos/id_authz_authn.png contextual_title1: Mieux communiquer sur OpenID et OAuth contextual_url1: 20090125-mieux-communiquer-sur-openid-et-oauth contextual_title2: Design centré sur l'activité ET sur l'attention contextual_url2: 20081015-design-centre-sur-activite-et-sur-attention contextual_title3: ★ Découvrons OAuth avec mixin (et django-oauth) contextual_url3: 20080713-decouvrons-oauth-avec-mixin-et-django-oauth
J’étais en train de lire le billet de Fred Cavazza sur MicroID et plus particulièrement les commentaires mais ça part un peu dans tous les sens, principalement pour un problème de vocabulaire. Je vais essayer de débroussailler un peu car la confusion est très souvent faite (notamment car auth peut signifier authorization et authentication en anglais d’où la nécessité de différencier authz et authn).
Identification : OpenID
Dans le cadre d’OpenID, l’identification permet uniquement de dire : cette URL est à moi et peut me représenter. Les providers proposent maintenant d’autres services mais la base c’est uniquement ça, aucune couche de confiance si ce n’est l’assurance d’avoir une URL derrière. Après si vous liez votre OpenID à votre page personnelle, vous ajoutez forcément un certain crédit à votre OpenID car vous garantissez l’appartenance de la page en question.
Il y a aussi des initiatives pour ajouter cette couche de confiance auprès de tiers dits de confiance (Etat, banques, etc) mais c’est une autre histoire.
Autorisation : OAuth
L’autorisation consiste à laisser l’accès ou pas à une donnée, que ce soit avec des tokens (comme OAuth), avec des URLs cachées, bref ce que vous voulez en fonction de la criticité de la donnée en question.
Aucune notion d’identité derrière ça, du moment qu’il a les clés on le laisse passer.
Ici aussi, il y a des initiatives pour combiner l’autorisation et l’identification, reste à voir comment prendre en compte l’ergonomie au passage.
Authentification : comptes utilisateurs
L’authentification cumule l’identification et l’autorisation pour un service donné, ça correspond bien souvent aux comptes utilisateurs qui définissent qui peut faire quoi sur un service. Lorsque vous vous authentifiez sur un service, vous prouvez que vous êtes la personne qui s’est préalablement enregistrée, la confiance est donc accordée par le service en question (elle peut se baser sur la vérification d’un email par exemple).
OpenID et OAuth peuvent faire partie intégrante d’un compte utilisateur comme cela est le cas pour mixin.
Le cas d’OpenID est un peu particulier en fait car les providers ont évolué et cette solution d’identification est maintenant bien souvent associée à une certaine confiance qui permet l’authentification (selon la confiance qu’accorde le service au provider). Le spam progresse forcément aussi dans cette voie donc on va probablement aller vers des whitelists de providers ce qui est complètement contraire à l’idée initiale de décentralisation du protocole mais bon certains semblent s’en réjouir. Allez comprendre.
Il n’y a pas de solution d’authentification globale à ma connaissance (enfin si on fait la somme des comptes Google + Yahoo on devrait s’en approcher…) et c’est pas plus mal compte tenu du pouvoir associé.
Et MicroID dans tout ça ?
Comme son nom l’indique, on parle ici d’identification et non de micro-authentification comme le laisse présager le titre du billet initial.
Si on lit la spec, les buts sont clairement identifiés :
MicroID is a lightweight identity technology that enables the creation of a portable identity token from any two Uniform Resource Identifiers [URI].
Such identity tokens are desirable because they:
- Enable individuals to assert ownership over information published and reputation earned on the Internet in a granular manner.
- Enable service providers to “stamp” information and reputation based on a validated URI associated with an individual who uses the service.
Si on commence par l’appartenance, si le hash est public (et c’est ce qui a l’air d’être mis en avant en le mettant dans la source de son site), cela n’a pas vraiment de valeur car (presque) tout le monde peut venir le récupérer pour l’utiliser ailleurs, au même titre qu’un pseudo/email/lien actuel.
S’il est privé, ça ne sert pas à grand chose non plus car il n’y a aucun moyen de vérifier à partir du hash.
Passons maintenant à l’aspect réputation, je ne vois pas non plus l’intérêt compte tenu du fait qu’il est impossible d’identifier la personne soumettant le contenu…
La seule solution possible que je vois c’est d’avoir un générateur par service qui ajoute son grain de sel et qui permet de vérifier que l’utilisateur est celui qu’il prétend être mais la simplicité en prend un sacré coup.
Au final, je ne vois pas vraiment l’intérêt de ce nouveau standard qui essaye manifestement de faire plus simple qu’OpenID mais là ça devient trop simple ! J’espère me tromper car je vois mal comment on peut investir autant de temps là-dedans + avoir des consommateurs aussi importants que digg ou plaxo, n’hésitez pas à éclairer ma microlanterne :-).