Comment la délégation OpenID fonctionne-t-elle sur la partie de confiance? Les spécifications ont-elles changé récemment?

Question

Considérez ce scénario. J'ai mon propre site Web, que j'utilise comme identifiant, mais j'utilise un fournisseur OpenID tiers (yahoo dans mon cas), comme décrit ici , pour vous connecter aux sites Web du groupe de confiance (RP) tels que stackoverflow et sourceforge.

Cela semblait être un geste judicieux:

• Je ne suis pas bloqué chez un fournisseur OpenID, car si / quand yahoo n'offre plus le service, ou commence à le facturer, ou si je ne leur fais plus confiance, je peux changer de fournisseur sans douleur
• Je n'ai pas la charge économique, administrative et de sécurité liée à l'installation et à la maintenance d'un fournisseur OpenID sur mon serveur

Question

Comment le RP doit-il fonctionner? Si j'ai bien compris, il convient d'utiliser l'identifiant I fourni et d'utiliser le fournisseur (yahoo) uniquement à des fins d'authentification (et non d'identification). Est-ce exact? Quelque chose a changé récemment? Juste pour être clair, je veux dire que mon identification devrait être

http://www.mysite.com/myPreferredUrl

et non

https://me.yahoo.com/myYahooId (qui correspond à l'emplacement de mon site Web " redirection "l'authentification décrite dans le site Web ci-dessus)

Note secondaire

Je pose cette question aussi parce que les choses semblent cassées en ce moment (elles allaient bien il y a quelques mois). Si j'essaie de me connecter à stackoverflow, j'écris l'URL mysite.com, je suis correctement " redirigé " sur le site Web yahoo sur lequel je me connecte, il me demande si je souhaite "continuer sur stackoverflow", je réponds oui, il "redirige" et sur le site stackoverflow, je vois "Ceci est un OpenID que nous n’avons pas vu auparavant", il affiche mon identifiant yahoo et je suis en fait bloqué!

Est-ce un bug ou est-ce qu'il me manque quelque chose?

PS: si vous vous demandez comment j'écris cette question, c’est que, sur l’une des nombreuses machines que j’utilise, un navigateur possède toujours un cookie valide ....

EDIT: La réponse d’Andrew Arnott ci-dessous suggérait un moyen de régler mon problème (c’est-à-dire de changer de fournisseur). Mais quelques détails m'intéressent toujours: qu'est-ce qui a changé d'OpenID 1.1 à 2.0, à propos de la délégation? Pourquoi, dans les spécifications, il a été choisi de laisser le fournisseur "break" " la delegation? Plus vous expliquez, meilleures sont les chances de voir votre réponse acceptée.

Answer 1

Je pense que la réponse d'Andrew est assez précise. La seule chose que je puisse ajouter concerne un peu la façon dont les spécifications v2.0 ont été appliquées, permettant ainsi au fournisseur de choisir de ne pas utiliser la délégation. Je pense que l’un des facteurs de motivation était la sélection d’identité dirigée par le serveur, dans laquelle l’utilisateur ne faisait que fournir "yahoo.com". (ou cliquez sur le bouton Yahoo), puis leur ID choisi revient du serveur dans la réponse id_res. Cela permet également au serveur de proposer, par exemple, le choix de l'identifiant à envoyer (comme le fait Yahoo) ou d'envoyer un identifiant unique à chaque RP (comme le fait Google).

Cela signifie également que toutes les informations nécessaires se trouvent dans une réponse id_res , ce qui signifie que le RP n'a pas besoin de stocker l'état à partir de sa demande checkid pour pouvoir traiter la réponse. En fait, un fournisseur pourrait envoyer une réponse id_res directement au RP sans que le RP ne l'engage avec une requête checkid .

Un fournisseur v1.x ignorait complètement à quel moment la délégation se déroulait en soirée. Cette conception a empêché un fournisseur de choisir même de ne pas prendre en charge la délégation, mais elle a également résolu certains problèmes d'interface utilisateur. ce serait vous demander si vous souhaitez fournir le "joe.coolprovider.com" " Identifiant lorsque vous utilisiez réellement votre délégué " joesmith.org " ID.

Donc, il y a un compromis. La délégation est toujours possible. L’espoir était donc que les utilisateurs qui souhaitaient réellement une délégation (qui, avouons-le, se laisserait prendre au piège par le nombre d’utilisateurs de ces grands sites) puissent choisir des fournisseurs offrant les fonctionnalités dont ils ont besoin. (En d’autres termes, laissez le marché se battre.)

Answer 2

Je ne pense pas que Yahoo supporte la délégation OpenID. Autrement dit, StackOverflow et d’autres RP peuvent effectuer une découverte sur votre propre identifiant et configurer correctement la demande d’autorisation de délégation, mais Yahoo pourrait choisir (sans contredit contre la spécification) d’envoyer une assertion d’identité pour leur propre identifiant plutôt que celle fournie par le RP.

Les spécifications n’ont pas changé d’OpenID 1.1 à 2.0. Les spécifications ne suggèrent ni n'approuvent le comportement de Yahoo!, et seul Yahoo peut commenter avec autorité leur raisonnement.

La délégation StackOverflow fonctionne toujours. Yahoo vous a brisé, semble-t-il. Je vous suggère de tirer parti de ce que la délégation vous a acheté en modifiant à qui vous déléguez l'authentification. www.myopenid.com, par exemple, prend en charge la délégation. Si vous modifiez votre propre identifiant pour indiquer cela, vous devriez pouvoir revenir à StackOverflow sous votre ancien statut. :)