2009-07-20 10 views
6

Je suis en train de débattre de savoir si je devrais utiliser la connexion OpenID pour l'un de mes sites Web. OpenID peut être plus difficile à implémenter parce que j'ai déjà écrit un code d'enregistrement et de connexion, mais ce n'est qu'une question de temps. Quels sont les avantages et les inconvénients de l'utilisation d'OpenID par rapport à, disons, un système de compte d'utilisateur de site Web traditionnel.Quels sont les avantages et les inconvénients de l'utilisation d'OpenID?

Répondre

5

Avantages

vous avez une signature unique qui est en fait assez cool, en particulier pour les personnes ayant un grand nombre de comptes ici et là.

Le serveur OpenID fournit des informations de base sur l'utilisateur, ce qui évite d'avoir à écrire les informations de base habituelles à chaque fois. Dans ce sens, vous évitez les tracas à vos utilisateurs.

Il améliore assez bien le mécanisme traditionnel utilisateur/passe. Il existe de nombreux sites fournissant les deux systèmes en même temps.

Confère la confiance de l'honnêteté de plusieurs parties à une seule personne. Pour l'instant, je ne sais pas si l'un des sites sur lesquels je suis enregistré stocke mon mot de passe en texte clair pour le voler et essaie de l'utiliser sur d'autres sites en supposant que j'ai le même mot de passe.

L'avantage technique de la délégation. Vous n'êtes pas obligé d'utiliser le même fournisseur. Vous pouvez changer.

Inconvénients

Vous devez toujours fournir utilisateur/mot de passe pour ceux qui ne comprennent pas le nouveau paradigme ou ils n'ont pas Openid (peut-être qu'ils ont, mais ils ne savent pas) . Si vous tentez de répondre à un large éventail de personnes, vous pourriez les effrayer.

Aussi, je ne l'utiliserais pas pour quelque chose de sérieux. Je ne ferais pas confiance à ma banque en me demandant de me connecter avec mon openid, mais aussi de nombreux sites de commerce électronique. C'est bon pour des choses sans importance.

Le fournisseur openid peut suivre les habitudes de l'utilisateur, car il reçoit toutes les demandes d'authentification. C'est pourquoi j'ai déployé mon fournisseur personnel.

Enfin, pour autant que je sache, de nombreux cas de serveurs openid déplacent le mot de passe en clair, mais c'est ce que je comprends et je peux me tromper. J'ai déployé mon propre fournisseur openid, et je suis allé beaucoup pour que le mot de passe a été transporté via https, même si mon openid est marqué comme http

1

Le principal avantage que je vois, mais pas nécessairement applicable dans votre cas si vous voulez garder votre système existant, c'est que je n'ai pas à vous soucier de stocker les mots de passe.

Trop de gens utilisent le même mot de passe (ou un petit ensemble de mots de passe) pour tout, donc si mon site était compromis (et j'espérais être suffisamment compétent pour l'éviter, mais la sécurité est multi-couches bête, donc tout ce qui peut ajouter une sécurité supplémentaire est bon dans mon livre) alors l'attaquant n'a pas pu obtenir le mot de passe.

Pour l'utilisateur, ils peuvent maintenant légitimement avoir un seul mot de passe pour tout. Ils utilisent un OpenID Provider en qui ils ont confiance plutôt que d'avoir à faire confiance à n'importe quel dick ou harry sur internet avec un site web.

1

Prenant bien SO comme un exemple, il prend en charge les deux. Je me connecte en utilisant mon compte Google via OpenID, mais j'ai toujours besoin d'un compte/nom d'utilisateur pour créer un lien vers mon OpenID.Je suppose que vous autorisez uniquement les connexions via OpenID mais pas pour vos utilisateurs de se connecter en utilisant votre site en tant que serveur OpenID.

Donc, pour éclaircir les choses; Vous pouvez utiliser beaucoup de votre code de connexion/déconnexion et vous en aurez besoin car la seule différence est que vous vous authentifiez via un tiers au lieu de votre propre base de données. En pseudo-code, imaginez ceci:

authenticate_from_db(String username, String password) 
{ 
     fetch username and password where username = username 
     if username = username and password = hash_of(password) 
     { 
      return true; 
     } 
     else 
     { 
      return false; 
     } 
} 

authenticate_from_openid(String openId_provider) 
{ 
    provider = contact_openID_provider(openID_provider) 
    if(provider) 
    { 
     login.username = map(returned_user, your_db) 
     return true 
    } 
    else 
    { 
     return false; 
    } 
} 

Donc, vous voyez, la plupart du temps le processus d'authentification est changé alors que le vôtre est encore utilisé.

L'avantage est assez clair:

  • Permettre aux utilisateurs de se connecter avec des comptes existants par leur fournisseur OpenID.
  • utilisateurs existants pourraient éventuellement connexion par leur fournisseur OpenID

Les inconvénients sont (je pourrais imaginer):

  • fournisseurs OpenID Hostile (? Spam) authentifier leurs spambots etc
  • Autres sécurité problèmes en permettant à un tiers d'authentifier vos utilisateurs

Je tiens à souligner que soutenir OpenID ne devrait rien changer pour vos utilisateurs existants.

Les utilisateurs d'OpenID doivent toujours posséder un compte, ils sont simplement authentifiés par un tiers.

+0

En effet, OpenID constitue l'élément d'authentification (qui ils sont). Le compte d'utilisateur dans votre application définit l'élément d'autorisation (ce qu'ils peuvent faire). –

Questions connexes