OpenID

OpenID Authentication 1.1 (fr)

English | 日本語 | ‪中文(中国大陆)‬ | Français | +/-

Résumé

La spécification OpenID Authentication fournit un moyen de prouver qu'un utilisateur final possède une adresse URL d'identité. Cela est possible sans qu'il ait à présenter son mot de passe, son adresse électronique ou quoique ce soit qu'il ne veuille pas.

OpenID est entièrement décentralisé, c'est-à-dire que quiconque peut choisir d'être un consommateur ou un fournisseur d'identités sans devoir s'enregistrer ou être approuvé par une autorité centrale. L'utilisateur final peut choisir le fournisseur d'identités qu'il souhaite utiliser et conserver son identité d'un fournisseur à l'autre.

Bien que rien dans le protocole n'oblige à utiliser du JavaScript ou des navigateurs récents, le schéma d'authentification s'accorde très bien avec les mises en œuvre de type « AJAX », si bien qu'un utilisateur final peut prouver son identité à un consommateur sans devoir quitter la page où il se trouve.

La spécification OpenID Authentication n'offre aucun mécanisme pour échanger des informations de profil, quoique les consommateurs d'une identité puisse apprendre plus sur un utilisateur final de n'importe quels documents publics sémantiquement intéressants qui y sont reliés (FOAF, RSS, Atom, vCARD, etc.) Des extensions sont en cours d'élaboration sur les fondations établies par OpenID Authentication pour disposer de mécanismes pour l'échange d'informations de profil.

Contents


Notation du niveau d'obligation

Les mots-clés « DOIT », « NE DOIT PAS », « OBLIGATOIRE », « DEVRA », « NE DEVRA PAS », « DEVRAIT », « NE DEVRAIT PAS », « RECOMMANDÉ », « PEUT » et « OPTIONNEL » dans ce document doivent être interprétés selon le document RFC 2119[1].

Terminologie

Utilisateur final :

L'utilisateur humain réel qui veut prouver son identité à un consommateur.

Identificateur :

Un identificateur est juste une adresse URL. Le processus entier du protocole OpenID Authentication consiste à prouver qu'un utilisateur final est (possède) une adresse URL.

Identificateur déclaré :

Un identificateur que l'utilisateur final dit posséder, sans toutefois que le consommateur ne l'ait vérifié.

Identificateur vérifié :

Un identificateur dont l'utilisateur final a prouvé la possession auprès du consommateur.

Consommateur :

Un service Web qui attend la preuve que l'utilisateur final possède l'identificateur déclaré.

Fournisseur d'identités :

Également appelé « fournisseur d'id » ou « serveur ». C'est le serveur OpenID Authentication contacté par le consommateur pour une preuve chiffrée que l'utilisateur final possède l'identificateur déclaré.
Les modalités de l'authentification de l'utilisateur final auprès de son fournisseur d'identités ne sont pas du ressort de la spécification OpenID Authentication.

Agent utilisateur :

Le navigateur de l'utilisateur final. Aucun module d'extension ni script JavaScript spéciaux ne sont obligatoires.

Aperçu

La transformation du document HTML en un identificateur

Pour que le consommateur sache quel fournisseur d'identités fait autorité pour un identificateur, l'utilisateur final doit ajouter du balisage dans la section HEAD du document HTML trouvé à son adresse URL. Il n'est PAS OBLIGATOIRE que l'hôte du document HTML soit également le fournisseur d'identités de l'utilisateur final : l'adresse URL de l'identificateur et le fournisseur d'identités peuvent être des services entièrement découplés.

Pour utiliser http://example.com/ comme identificateur de l'utilisateur final et http://openid.example.com comme son fournisseur d'identités, il faudrait ajouter le balise suivant à la section HEAD du document HTML retourné pour l'adresse URL de l'identificateur.

<link rel="openid.server" href="http://openid.example.com/">

La délégation de l'authentification

Si l'hôte de l'utilisateur final est incapable de faire tourner un fournisseur d'identités, ou si l'utilisateur final souhaite en utiliser un fonctionnant sur un hôte différent, il leur faudra déléguer l'authentification. Par exemple, si l'hôte veut utiliser le site Web http://www.example.com/ comme identificateur, mais n'a pas la capacité (ou l'utilisateur final le désir) de faire tourner un fournisseur d'identités.

Si l'hôte (ou l'utilisateur) a un compte chez LiveJournal (disons, sous le nom d'utilisateur « exampleuser ») et sait que LiveJournal dispose d'un fournisseur d'identités OpenID qui évaluera s'il possède l'identificateur http://exampleuser.livejournal.com/, alors il pourra déléguer l'authentification au fournisseur d'identités de LiveJournal.

Donc, pour utiliser www.example.com comme identificateur, mais en réalité que le consommateur vérifie http://exampleuser.livejournal.com/ auprès du fournisseur d'identités situé à http://www.livejournal.com/openid/server.bml, il ajoutera les balises suivantes dans la section HEAD du document HTML retourné de l'adresse URL de l'identificateur.

<link rel="openid.server" href="http://www.livejournal.com/openid/server.bml">

<link rel="openid.delegate" href="http://exampleuser.livejournal.com/">

À ce moment, le consommateur voyant cela, il discutera avec http://www.livejournal.com/openid/server.bml et lui demandera si l'utilisateur final est bien exampleuser.livejournal.com, sans jamais mentionner www.example.com nulle part dans l'échange.

L'avantage principal de la méthode est que l'utilisateur final peut garder son identificateur plusieurs années, même avec la disparition des services : il devra juste changer de délégation.

Notes importantes

  • L'adresse URL déclarée openid.server PEUT contenir des paramètres de requête existants et ils DOIVENT être correctement préservés si on ajoute des paramètres supplémentaires. Par exemple, en n'ajoutant pas un deuxième point d'interrogation s'il en existe déjà un.
  • Les adresses URL openid.server et openid.delegate DOIVENT être des adresses absolues. Le consommateur NE DOIT PAS essayer de résoudre les adresses URL relatives.
  • Les adresses URL openid.server et openid.delegate NE DOIVENT PAS inclure d'autres entités que « & », « < », « > » et « " ». Les autres caractères qui seraient invalides dans le document HTML ou qui ne seraient pas représentables avec le codage de caractères du document DOIVENT être échappés au moyen du mécanisme %xx décrit dans le document RFC 2396[2].

La soumission de l'identificateur déclaré

En continuant cet exemple, l'utilisateur final visite le site d'un consommateur utilisant OpenID Authentication. Le consommateur présente à l'utilisateur final un champ de formulaire où saisir l'adresse URL de son identificateur.

Par exemple : 

     --------------------------------
     |[logo]example.com             | [Envoyer]
     --------------------------------

Notes importantes

  • Il est RECOMMANDÉ à chaque consommateur de placer le logo OpenID au début du champ de formulaire dans lequel l'utilisateur final saisit l'adresse URL de son identificateur.
  • L'utilisateur n'est PAS OBLIGÉ de préfixer l'adresse URL de son identificateur par « http://  » ni de le préfixer par un caractère barre oblique « / » finale. Le consommateur DOIT canoniser l'adresse URL de l'identificateur, en suivant les redirections, et noter l'adresse URL finale. L'adresse URL canonisée finale est l'identificateur de l'utilisateur final.
  • Il est RECOMMANDÉ de nommer le champ de formulaire "openid_url" afin que l'agent utilisateur le remplisse automatiquement avec l'adresse URL de l'identificateur de l'agent utilisateur, de la même façon que le monde du commerce électronique tend à utiliser des conventions telles que « address1 » et « address2 ».

Le site du consommateur récupère l'adresse URL de l'identificateur

Le consommateur cherche alors le document repéré par l'identificateur déclaré de l'utilisateur final. Le consommateur analyse ensuite la section HEAD à la recherche des déclarations « openid.server » et « openid.delegate » (optionnelle).

Notes importantes

  • L'utilisateur final pourrait être un usurpateur qui essaye de pousser le consommateur à se connecter à un réseau interne, une mise en attente (N.d.T. tarpit), etc. On RECOMMANDE au consommateur d'utiliser une bibliothèque HTTP paranoïaque telle que LWPx::ParanoidAgent pour se prémunir de ces types d'attaques.
  • Le consommateur DOIT gérer la délégation.

Mode intelligent contre mode passif

Le protocole OpenID Authentication gère à la fois un « mode intelligent » et un « mode passif » pour tenir compte des consommateurs avec des capacités différentes. Un consommateur intelligent fait un petit peu plus au début pour s'épargner du travail plus tard, mais nécessite une mise en cache locale des informations d'état. Un consommateur passif est absolument sans état, mais nécessite une requête HTTP supplémentaire.

Notes importantes pour le mode intelligent

  • Il est RECOMMANDÉ au consommateur de d'abord soumettre une requête associée au fournisseur d'identités de l'utilisateur final et de réclamer un secret partagé si le consommateur n'en a pas déjà un en cache. Ce secret partagé DEVRAIT être utilisé comme clé HMAC-SHA1 dans les requêtes de vérification d'identité futures jusqu'à son expiration.
  • Le secret partagé peut être échangé soit en clair, soit chiffré avec un secret Diffie-Hellman négocié. Remarquez que si on utilise un secret Diffie-Hellman, il ne sert qu'en mode associé (associate). Les modes checkid_immediate et checkid_setup supposent que le consommateur partage déjà un secret, quelle que soit la façon dont il l'aura obtenu.

Le consommateur vérifie l'identificateur

Le consommateur construit ensuite une adresse vers les adresses URL checkid_immediate (ou checkid_setup) du fournisseur d'identités et y oriente l'agent utilisateur.

En envoyant l'agent utilisateur là-bas, les cookies de l'utilisateur final et autres titres d'accès, quels qu'ils soient, sont retournés à son fournisseur d'identités sécurisé. Le fournisseur d'identités fait son œuvre, accroche sa réponse à la fin de l'adresse URL openid.return_to fournie et envoie l'agent utilisateur chez le consommateur.

Modes

associate

  • Description : Établit un secret partagé entre le consommateur et le fournisseur d'identités.
  • Méthode HTTP : POST
  • Flux : Consommateur -> Fournisseur d'identités -> Consommateur

Paramètres de la requête

  • openid.mode
Valeur : "associate"
  • openid.assoc_type
Valeur : Type d'association préféré
Défaut : "HMAC-SHA1"
Note : Optionnel. Une seule valeur pour l'instant.
  • openid.session_type
Valeur : Blanc ou "DH-SHA1"
Défaut : Blanc (texte en clair)
Note : Il est RECOMMANDÉ d'utiliser le mode DH-SHA1 pour chiffrer le secret partagé.
  • openid.dh_modulus
Valeur : base64(btwoc(p))
Note : Cf. Annexe A.1 pour la valeur par défaut de p.
  • openid.dh_gen
Valeur : base64(btwoc(g))
Défaut : g = 2
Note : Seulement si utilisation du type de session DH-SHA1. Devrait être indiqué si openid.dh_modulus est défini.
  • openid.dh_consumer_public
Valeur : base64(btwoc(g ^ x mod p))
Note : OBLIGATOIRE si utilisation du type de session DH-SHA1.

Paramètres de la réponse

Format de la réponse : Des couples clé-valeur

  • assoc_type
Valeur : Le type d'association du descripteur (N.d.T. handle) retourné.
Note : Le seul mode courant est HMAC-SHA1, et tous les consommateurs DOIVENT le gérer. À la mise en cache, le consommateur DOIT associer un descripteur assoc_handle à son secret et à son type d'association (assoc_type).
  • assoc_handle
Valeur : Le descripteur d'association à fournir dans les transactions futures.
Note : Les consommateurs NE DOIVENT PAS réutiliser ce descripteur d'association au-delà de la valeur expires_in correspondante.
  • expires_in
Valeur : Le nombre de secondes pendant lesquelles ce descripteur d'association est valide en ASCII base10.
  • session_type
Valeur : Le mode de chiffrement choisi par le fournisseur d'identités. Il PEUT être blanc, absent ou valoir "DH-SHA1".
  • dh_server_public
Valeur : base64(btwoc(g ^ y mod p))
Description : La clé publique Diffie-Hellman[3] RFC 2631 du fournisseur d'identités, si utilisation de DH-SHA1.
  • enc_mac_key
Valeur : base64(SHA1(btwoc(g ^ (xy) mod p)) XOR secret(assoc_handle))
Description : Le secret partagé chiffré, si utilisation de DH-SHA1.
  • mac_key
Valeur : base64(secret(assoc_handle))
Description : Le secret partagé en clair, si non utilisation de DH-SHA1.

Notes supplémentaires

  • Un consommateur peut demander au serveur un chiffrement DH-SHA1 et recevoir un secret en clair. Si cela vous gêne, n'utilisez pas le descripteur et utilisez le mode passif à la place avec ce fournisseur d'identités.

Si quelqu'un reniflait le secret en clair, cela n'aurait pas d'importance puisque vous n'accepterez jamais d'interrogations utilisant ce descripteur d'association. Si le fournisseur d'identités ne peut pas employer DH-SHA1, c'est qu'il est probablement bridé d'une certaine façon, mais l'utilisation du mode passif est toujours sûre sinon un peu lente.

  • Si le fournisseur d'identités choisit la clé privée du serveur 1 <= y < p-1. Le secret DH-SHA1 partagé est alors g ^ xy mod p = (g ^ x) ^ y mod p = (g ^ y) ^ x mod p. Pour plus d'informations, consultez la documentation Crypt::DH.
  • La clé mac_key sous-jacente DOIT être de même longueur que la sortie de la fonction de hachage H - dans ce cas, 160 bits (20 octets) pour DH-SHA1.
  • Si le fournisseur d'identités ne gère pas DH-SHA1, il IGNORERA les champs DH-SHA1 dans la requête et répondra exactement comme à une requête non-DH-SHA1.
  • Si utilisation de DH-SHA1, la clé résultante DEVRAIT être traitée comme une chaîne binaire.
  • Les entiers sont représentés pour la plupart en gros-boutiens (N.d.T. big-endian) signés en complément à deux, codés en base64. En d'autres termes, btwoc est une fonction qui accepte un entier bigint et retourne sa notation gros-boutienne en complément à deux la plus courte.

checkid_immediate

  • Description : Demande au fournisseur d'identités si l'utilisateur final possède l'identificateur déclaré, et reçoit une réponse immédiate "yes" ou "can't say".
  • Méthode HTTP : GET
  • Flux : Consommateur -> Agent utilisateur -> Fournisseur d'identités -> Agent utilisateur -> Consommateur

Paramètres de la requête

  • openid.mode
Valeur : "checkid_immediate"
  • openid.identity
Valeur : Identificateur déclaré
  • openid.assoc_handle
Valeur : Le descripteur assoc_handle de la requête associée.
Note : Optionnel. Le consommateur DOIT utiliser check_authentication si aucun descripteur d'association n'est fourni ou si le fournisseur d'identités l'estime invalide.
  • openid.return_to
Valeur : L'adresse URL où le fournisseur d'identités DEVRAIT renvoyer l'agent utilisateur.
  • openid.trust_root
Valeur : L'adresse URL que le fournisseur d'identités DEVRA demander à l'agent utilisateur de croire.
Défaut : L'adresse URL return_to
Optionnel. L'adresse URL que l'utilisateur final DEVRA réellement voir pour l'approuver.

Paramètres de la réponse

Format de la réponse : les arguments de la chaîne de requête

Toujours envoyé
  • openid.mode
Valeur : "id_res"
Envoyé si l'évaluation a échoué
  • openid.user_setup_url
Valeur : L'adresse URL vers laquelle rediriger l'agent utilisateur afin que l'utilisateur final puisse faire le nécessaire pour satisfaire à l'évaluation.
Envoyé si l'évaluation a réussi
  • openid.identity
Valeur : Identificateur vérifié
  • openid.assoc_handle
Valeur : Le descripteur d'association opaque utilisé pour trouver la clé HMAC de la signature.
  • openid.return_to
Valeur : Une copie littérale du paramètre URL return_to envoyé dans la requête, avant que le fournisseur d'identités ne l'ait modifié.
  • openid.signed
Valeur : Une liste de champs signés séparés par des virgules.
Note : Les champs sans préfixe « openid. » couverts par la signature. Par exemple, "mode,identity,return_to".
  • openid.sig
Valeur : base64(HMAC(secret(assoc_handle), token_contents)
Note : Où token_contents est une chaîne de format clé-valeur de toutes les clés et valeurs signées dans cette réponse. Elles DOIVENT être dans le même ordre que celui de la liste du champ openid.signed. Le consommateur DEVRA recréer la chaîne token_contents avant de vérifier la signature. Cf. Annexe D.
  • openid.invalidate_handle
Valeur : Optionnel. Le descripteur d'association envoyé dans la requête si le fournisseur d'identités ne l'a pas accepté ou reconnu.

Notes supplémentaires

  • Ce mode est couramment utilisé pour les mises en œuvre de style « AJAX ». Le mode plus classique pour vérifier un identificateur déclaré est checkid_setup.
  • Le fournisseur d'identités DEVRAIT seulement évaluer les adresses URL qu'il gère/produit directement. Si l'utilisateur final veut évaluer d'autres adresses URL hors du domaine de ce fournisseur d'identités, il DOIT utiliser la délégation.
  • L'adresse URL openid.return_to fournie PEUT contenir une chaîne de requête, et le fournisseur d'identités DOIT la préserver en y accrochant les paramètres de réponse à la fin. Le consommateur OpenID DEVRAIT ajouter un nonce auto-signé, avec l'horodatage local du consommateur, dans le paramètre URL openid.return_to afin d'empêcher les attaques par répétition. Le détail de la mise en œuvre est laissé au consommateur.

En revanche, puisque l'adresse URL openid.return_to est signée par le fournisseur d'identités, le consommateur peut s'assurer que des tiers extérieurs n'ont pas envoyés de réponses id_res avec des adresses URL openid.return_to et des signatures non accordées.

  • Si le fournisseur d'identités n'avait pas accepté/reconnu pour une raison quelconque le descripteur assoc_handle fourni,

il choisira le sien propre et copiera celui fourni dans le paramètre openid.invalidate_handle, pour avertir le consommateur de cesser de l'utiliser. Le consommateur DEVRAIT alors l'envoyer en même temps qu'une requête check_authentication pour vérifer qu'elle n'est plus valide en réalité.

  • Si l'évaluation de l'identificateur échoue, le fournisseur d'identités fournit le paramètre openid.user_setup_url où l'utilisateur final pourra faire le nécessaire pour satisfaire à l'évaluation, qu'il s'agisse d'ouvrir une session, de paramétrer des permissions, etc. Le serveur DEVRAIT retourner une adresse URL qui n'implique rien concernant ce qui est nécessaire, de sorte que le consommateur soit laissé dans l'ignorance du pourquoi de l'échec de l'évaluation.

En fin de compte, la manipulation du fournisseur d'identités DEVRAIT renvoyer l'utilisateur final à l'adresse URL openid.return_to, agissant comme une réponse checkid_setup, avec pour mode soit "id_res", soit "cancel".

  • L'adresse URL openid.return_to DOIT descendre de openid.trust_root, ou le fournisseur d'identités DEVRAIT retourner une erreur. À savoir, le schéma et le port de l'adresse URL DOIVENT correspondre. Si présent, le chemin DOIT être égal à ou sous la valeur de openid.trust_root, et les domaines DOIVENT correspondre sur les deux, ou sous la valeur de openid.trust_root contiennent un joker comme http://*.example.com. Le joker DEVRA seulement être au début. Il est RECOMMANDÉ aux fournisseurs d'identités de protéger leurs utilisateurs finaux de requêtes telles que http://*.com/ ou http://*.co.uk/.
  • Dans la réponse, la signature du fournisseur d'identités DOIT couvrir openid.identity et openid.return_to.

checkid_setup

  • Description : Demande au fournisseur d'identités si l'utilisateur final possède l'identificateur déclaré, mais s'il veut bien attendre sa réponse. Le consommateur orientera l'agent utilisateur vers le fournisseur d'identités pour un court instant, qui lui répondra soit "yes", soit "cancel".
  • Méthode HTTP : GET
  • Flux : Consommateur -> Agent utilisateur -> [Fournisseur d'identités -> Agent utilisateur ->]+ Consommateur

Paramètres de la requête

  • openid.mode
Valeur : "checkid_setup"
  • openid.identity
Valeur : Identificateur déclaré
  • openid.assoc_handle
Valeur : Le descripteur assoc_handle de la requête associée.
Note : Optionnel. Le consommteur DOIT utiliser check_authentication si aucun descripteur d'association n'est fourni ou si le fournisseur d'identités l'estime invalide.
  • openid.return_to
Valeur : L'adresse URL vers où le fournisseur d'identités DEVRAIT renvoyer l'agent utilisateur.
  • openid.trust_root
Valeur : L'adresse URL que le fournisseur d'identités DEVRA demander à l'utilisateur final de croire.
Défaut : L'adresse URL return_to
Optionnel. L'adresse URL que l'utilisateur final DEVRA réellement voir pour approuver.

Paramètres de réponse

Format de la réponse : les arguments de la chaîne de requête

Toujours envoyé
  • openid.mode
Valeur : "id_res" ou "cancel"
Envoyé si l'évaluation a réussi
  • openid.identity
Valeur : Identificateur vérifié
  • openid.assoc_handle
Valeur : Un descripteur d'association opaque utilisé pour trouver la clé HMAC de la signature.
  • openid.return_to
Valeur : Une copie littérale du paramètre URL return_to envoyé dans la requête, avant que le fournisseur d'identités ne l'ait modifié.
  • openid.signed
Valeur : Une liste de champs signés séparés par des virgules.
Note : Les champs sans préfixe « openid. » couverts par la signature. Par exemple, "mode,identity,return_to".
  • openid.sig
Valeur : base64(HMAC(secret(assoc_handle), token_contents)
Note : Où le paramètre token_contents est une chaîne de format clé-valeur de toutes les clés et valeurs signées dans cette réponse. Elles DOIVENT être dans le même ordre que celui de la liste du champ openid.signed. Le consommateur DEVRA recréer la chaîne token_contents avant de vérifier la signature. Cf. Annexe D.
  • openid.invalidate_handle
Valeur : Optionnel. Le descripteur d'association envoyé dans la requête si le fournisseur d'identités ne l'a pas accepté ou reconnu.

Notes supplémentaires

  • Dans la réponse, la signature du fournisseur d'identités DOIT couvrir les paramètres openid.identity et openid.return_to.
  • Dans beaucoup de cas, le consommateur ne récupèrera pas de mode annulation (cancel) ; l'utilisateur final simplement quittera ou retournera en arrière dans son agent utilisateur. Mais s'il est retourné, le consommateur DEVRAIT revenir à ce qu'il était en train de faire. En cas de mode annulation, les paramètres de réponse restants seront absents.

check_authentication

  • Description : Demande au fournisseur d'identités si un message est valide. Pour les consommateurs passifs sans état ou si vérification d'une réponse invalidate_handle.

ATTENTION : Valide seulement les signatures avec descripteurs d'association sans état. Les fournisseurs d'identités NE DOIVENT PAS valider la signature d'un descripteur d'association dont le secret est partagé avec quiconque. Ils DOIVENT distinguer leurs descripteurs d'association, ceux sans état de ceux associés, et ne proposer un service check_authentication que sur les descripteurs sans état.

  • Méthode HTTP : POST
  • Flux : Consommateur -> Fournisseur d'identités -> Consommateur

Paramètres de la requête

  • openid.mode
Valeur : "check_authentication"
  • openid.assoc_handle
Valeur : Le descripteur d'association de la réponse checkid_setup ou checkid_immediate.
  • openid.sig
Valeur : La signature de la requête checkid_setup ou checkid_immediate que le consommateur souhaite vérifier.
  • openid.signed
Valeur : La liste des champs signés de la requête checkid_setup ou checkid_immediate dont le consommateur souhaite vérifier la signature.
  • openid.*
Valeur : Le consommateur DOIT envoyer tous les paramètres de réponse openid.* de la liste openid.signed qu'il aura obtenus précédemment d'une requête checkid_setup ou checkid_immediate, leurs valeurs étant exactement celles retournées par le fournisseur d'identités.
  • openid.invalidate_handle
Valeur : Optionnel. Le descripteur d'association retourné via invalidate_handle.

Paramètres de la réponse

Format de la réponse : Des couples clé-valeur

  • openid.mode
Valeur : "id_res"
  • is_valid
Valeur : "true" ou "false"
Description : Booléen. Si la signature est valide ou non.
  • invalidate_handle
Valeur : Un descripteur d'association opaque
Description : Si présent, le consommateur DEVRAIT démettre (N.d.T. uncache) le descripteur d'association retourné du cache.

Notes supplémentaires

  • Les fournisseurs d'identités DOIVENT mettre en œuvre ce mode pour la reprise sur erreur (N.d.T. error recovery) et pour les consommateurs passifs, qui ne peuvent pas conserver un état localement, mais il est RECOMMANDÉ de l'utiliser le moins possible car il ne devrait pas être nécessaire la plupart du temps. Par contre, il est bon pour le débogage pendant qu'on développe sa bibliothèque consommateur.
  • Si vous recevez une réponse invalidate_handle au cours d'une requête checkid_setup ou checkid_immediate, cela signifie que le fournisseur d'identités n'a pas reconnu le descripteur d'association, peut-être l'a-t-il perdu, et il a du prendre le sien propre.

Cela signifie que le consommateur devra se rabattre sur le mode passif, puisque vous n'avez pas le secret partagé utilisé par le fournisseur d'identités. Pendant cette requête check_authentication, envoyez également la réponse invalidate_handle du fournisseur d'identités qui sera vérifiée pour voir s'il est réellement manquant/erroné.

  • Pour la vérification de la signature en utilisant des valeurs de requête openid.*, la valeur de openid.mode doit être changée pour "id_res".

La sécurité en question

  • Bien que le protocole OpenID Authentication cite souvent l'utilisation de HTTP, on peut utiliser HTTPS pour une sécurité accrue. Il est RECOMMANDÉ de l'utiliser en mode associé (associate), il protège des attaques de type homme au milieu, DNS et certaines attaques par hameçonnage (N.d.T. phishing).
  • Les consommateurs NE DEVRAIENT PAS utiliser d'éléments iframes ou de fenêtres surgissantes pour demander l'identifiant de connexion de l'utilisateur final via OpenID.

Annexe A. Les valeurs par défaut

Annexe A.1. La valeur P Diffie-Hellman

1551728981814736974712322577637155\ 3991572480196691540447970779531405\ 7629378541917580651227423698188993\ 7278161526466314385615958256881888\ 8995127215884267541995034125870655\ 6549803580104870537681476726513255\ 7470407658574792912915723345106432\ 4509471500722962109419434978392598\ 4760375594985848253359305585439638443

Annexe B. Les réponses d'erreurs

Cette section traite des erreurs de protocole/d'exécution, non des erreurs d'authentification. Les erreurs d'authentification sont définies dans le protocole.

  • Aucun code d'erreur n'est défini, uniquement le texte non structuré des erreurs en langage courant.
  • Si c'est une requête GET avec des arguments erronés, mais l'adresse URL openid.return_to est valide, alors le fournisseur d'identités DEVRA rediriger l'agent utilisateur avec le jeu openid.mode=error et openid.error=Error+Texte.
  • Si c'est une requête GET avec des arguments erronés et pas d'adresse URL openid.return_to, alors le fournisseur d'identités DEVRA retourner un code HTTP "400 Bad Request" avec un type de contenu (content-type) et un message d'erreur quelconques.
  • Si c'est une requête GET sans argument, le fournisseur d'identités DEVRA renvoyer un code HTTP 200 et un message d'erreur de type text/html disant "This is an OpenID server endpoint. For more information, see http://openid.net/".
  • Si c'est une requête POST avec des arguments erronés ou sans argument, le fournisseur d'identités DEVRA retourner un code HTTP "400 Bad Request" avec le format de réponse clé-valeur contenant la seule clé "error" avec le texte en langage courant. Le fournisseur d'identités peut ajouter des clés supplémentaires quelconques dans ce cas.

Annexe C. Le format clé-valeur

Des lignes telles que :

  • une_clé:une valeur
  • Il NE DOIT PAS y avoir d'espace avant et après le deux-points.
  • Les caractères nouvelle ligne DOIVENT être de type Unix, juste un caractère ASCII 10 (« \n »).
  • Les nouvelles lignes DOIVENT ÊTRE à la fin de chaque ligne ainsi qu'entre les lignes.
  • Le type MIME n'est pas défini, mais text/plain est RECOMMANDÉ.
  • Le codage des caractères DOIT ÊTRE UTF-8.

Annexe D. Les limites

  • Adresse URL d'identificateur : 255 octets maximum
  • Adresse URL de fournisseur d'identités : 2047 octets maximum, après les arguments URL ajoutés par le consommateur. Le point limite brut de l'adresse URL DEVRAIT rester bien en-deça de cette valeur.
  • Adresse URL return_to : 2047 octets maximum, après les arguments URL ajoutés par le fournisseur d'identités. L'adresse URL return_to brute DEVRAIT rester bien en-deça de cette valeur.
  • Descripteur assoc_handle : 255 caractères ou moins, et constitué seulement des caractères ASCII dans l'intervalle 33-126 inclus (c'est-à-dire les caractères imprimables non blancs).

Annexe E. Divers

  • Les horodates (N.d.T. timestamps) doivent être dans le format du W3C et doivent être dans le fuseau horaire UTC, signalé par un « Z ». Par exemple : 2005-05-15T17:11:51Z

Références normatives

  1. ↑ RFC 2119 Bradner, B., Les mots-clés à utiliser dans les RFC pour indiquer les niveaux d'obligation.
  2. ↑ RFC 2396 Berners-Lee, T., Identificateurs de ressources uniformes (URI) : Syntaxe générique.
  3. ↑ RFC 2631 Rescorla, E., La méthode de contrat de clé Diffie-Hellman.

Adresses des auteurs

David Recordon

Email : drecordon@verisign.com

Brad Fitzpatrick

Email : brad@danga.com

Retrieved from "http://wiki.openid.net/OpenID_Authentication_1.1_%28fr%29"