Cross Domain Login - Comment se connecter automatiquement à un utilisateur lors d'un transfert d'un domaine à un autre

Question

Nous offrons un certain nombre de services en ligne. Nous sommes tenus de développer un système qui offre une expérience simple/rapide pour les utilisateurs s'ils sont transférés d'un service (sur domain1.com) vers un autre service (sur domain2.com).

Existe-t-il un moyen sûr et sécurisé de se connecter automatiquement à un utilisateur automatiquement une fois qu'il a été transféré vers le nouveau service? Criez-moi si la solution ci-dessous est complètement non sûre/erronée.

Nous envisagions un système similaire à celui fourni par un certain nombre de services en ligne pour la récupération de mot de passe - ils sont envoyés par courriel un lien avec un hash unique qui expire, qui leur permet de changer leur mot de passe.

Le domain1.com génère un hachage unique et le stocke dans une base de données avec le hachage lié à un utilisateur avec un champ date/heure d'expiration.

L'utilisateur sera transféré à domain2.com/auto/?hash=d41d8cd98f00b204e9800998ecf8427e

domain2.com serait ensuite faire une demande de domain1.com avec le hachage pour obtenir les informations sur l'utilisateur. domain1.com supprimerait alors le hachage de la base de données. domain2.com enregistrerait l'utilisateur dedans et placerait le biscuit etc.

Quelque chose basé sur OpenID ou OAuth pourrait obtenir les mêmes résultats?

Answer 1

Si quelqu'un a pu jouer l'homme au milieu et saisir ce hachage, seraient-ils en mesure de voler le transfert de domaine croix? Évidemment, il doit être généré et envoyé au client avant qu'ils aient besoin de l'utiliser. Donc disons par exemple:

Je joue à l'homme au milieu espionnage sur Jack. Jack accède à domain1.com ce qui provoque la préparation et l'envoi d'un hachage de sorte que lorsqu'il accède au domain2.com, il peut envoyer ce hachage comme authentification. Alors qu'il accède à domain1.com, sa requête passe à travers moi, vous retournez la page, je prends le hachage et le laisse continuer. J'accède domain2.com en utilisant le hachage, vous me laissez maintenant dans domain2.com et supprimé le hachage. Il n'en est pas plus sage jusqu'à ce qu'il tente de se connecter au domain2.com et que ses informations d'identification ne soient plus valides.

Comment surmontez-vous cela?

Answer 2

Ceci est une bonne solution. Voici deux points à considérer:

Vous utilisez le terme «hash», mais vous ne savez pas quelles données vous allez hacher. Au lieu de cela, utilisez un "nonce": un grand nombre (128 bits) généré par un RNG de qualité cryptographique.

De même, vous ne l'avez pas spécifié, mais les communications entre l'utilisateur et les deux domaines, et entre les domaines eux-mêmes, doivent être sécurisées. Utilisez SSL pour authentifier les serveurs et garder le nonce confidentiel.

Answer 3

L'authentification unique (SSO) est conceptuellement assez simple.

• Vs utilisateur domain1.com.
• domain1.com voit il n'y a pas de cookie de session.
• domain1.com redirige vers sso.com
• sso.com présente page de connexion, et prendre les informations d'identification
• sso.com ensembles cookie de session pour l'utilisateur
• sso.com réoriente puis retour à domain1 à une url spéciale (comme domain1.com/ssologin)
• le ssologin URL contient un paramètre qui est fondamentalement "signé" par le sso.com. Cela pourrait être aussi simple qu'un base64 de crypter le loginid en utilisant une clé secrète partagée.
• domain1.com prend le jeton crypté, le décrypte, utilise le nouvel identifiant de connexion pour se connecter à l'utilisateur.
• domain1 définit le cookie de session pour l'utilisateur.

Maintenant, le cas suivant.

• frappe utilisateur domain2.com, qui suit domain1 et redirige vers sso.com
• sso.com a déjà un cookie pour l'utilisateur, donc ne présente pas la page de connexion
• sso.com redirige vers domain2.com les informations cryptées
• domain2.com se connecte à l'utilisateur.

Voilà les principes fondamentaux du fonctionnement. Vous pouvez le rendre plus robuste, plus riche en fonctionnalités (par exemple, c'est SSOn, mais pas SSOff, l'utilisateur peut se "déconnecter" de domain1, mais toujours être connecté à domain2). Vous pouvez utiliser clés publiques pour la signature des informations d'identification, vous pouvez avoir des demandes pour transférer plus d'informations (comme les droits d'autorisation, etc) à partir du serveur SSO. Vous pouvez avoir une intégration plus intime, telle que les domaines vérifiant régulièrement que l'utilisateur dispose toujours des droits du serveur SSO.

Mais le cookie handshake via le navigateur en utilisant les redirections est la base clé sur laquelle toutes ces solutions SSO sont basées.

Answer 4

Qu'en est-il du référencement? Il semble que chaque demande avant la connexion réussie est redirigée vers un autre domaine et retour. Je dirais que c'est très moche. Quels en-têtes devriez-vous envoyer? 301 à SSO, puis 301 à la page d'origine? Donc le moteur de recherche est "demandé" de changer son index pour cette page deux fois?

Answer 5

Il ne sert à rien d'utiliser le protocole SSL pour la connexion entre domaines, sauf si vous utilisez le protocole SSL pendant toute la session. Il est aussi facile de voler un cookie de session que d'utiliser un hash dans une URL. Quel est l'intérêt de cacher le hachage dans SSL si le reste de la session n'est pas sécurisé?

La méthode donnée en haut est à peu près la méthode standard. Que vous choisissiez d'utiliser des protocoles sécurisés est une toute autre affaire, mais il serait inutile de seulement chiffrer une partie de la session.