Le système que vous voulez devrait probablement travailler quelque chose comme ceci:
- Lorsqu'un utilisateur visite le serveur « autre » sans jeu de cookie de session, le serveur redirige l'utilisateur vers une URL spéciale sur l'application App Engine - utilisons/authentifions - avec un paramètre de chaîne de requête 'suivant' qui fournit l'URL de l'étape suivante (décrite au point 3).
- Lorsque App Engine reçoit une demande d'authentification /, il vérifie si l'utilisateur est connecté. Si ce n'est pas le cas, il les invite à se connecter. Ensuite, il génère un jeton pour la session de l'utilisateur, le signe avec un HMAC, utilise un secret partagé par les deux serveurs et redirige l'utilisateur vers l'URL fournie à l'étape 1 , avec le HMAC inclus dans la chaîne de requête. Lorsque le serveur 'autre' reçoit une requête à son URL spéciale (spécifiée à l'étape 1), il valide que HMAC correspond, en utilisant le secret partagé, et si c'est le cas, utilise son propre support de session pour définir un cookie sur le navigateur de l'utilisateur sous son domaine, pour garder une trace de l'utilisateur à partir de là. Si le serveur «autre» a besoin d'obtenir plus d'informations sur l'utilisateur, il peut utiliser une API qu'il partage avec le serveur App Engine pour demander, hors bande, plus d'informations sur l'utilisateur à l'aide du jeton qu'il a reçu. et le secret partagé.
Ceci est très similaire à la procédure utilisée par OAuth, mais entièrement non interactif pour l'utilisateur. C'est également la procédure que les systèmes SSO tels que les comptes Google utilisent pour «transférer» des sessions à d'autres parties de confiance.
Avez-vous vraiment besoin d'envoyer des utilisateurs à ces autres serveurs? Ne pourriez-vous pas simplement les utiliser comme backend, avec App Engine communiquant avec eux pour le compte de l'utilisateur? –