Лучше всего передать GUID через сессия.

http://www.w3schools.com/ASP/asp_sessions.asp

ИЛИ, поскольку это 2 разных сервера, передайте информацию методом POST:

http://www.w3schools.com/aspnet/aspnet_forms.asp

Другая возможность - сохранить состояние сеанса в базе данных на локальном сервере и получить удаленный доступ к этой базе данных с другого сервера, чтобы узнать, успешно ли пользователь вошел в систему и в пределах лимита времени сеанса.

Имея это в виду, вы также можете выполнить всю аутентификацию удаленно. Удаленно подключитесь к локальной базе данных с удаленного сервера и проверьте учетные данные оттуда ... таким образом вы сможете сохранить сеанс и / или cookie на удаленном сервере.

Я бы рекомендовал ПРОТИВ предложение скрытого поля, поскольку он полностью противодействует тому, что вы пытаетесь сделать! Вы пытаетесь скрыть GUID в URL-адресе, но публикуете ту же информацию в своем HTML-коде! Это не способ сделать это.

Лучшим выбором является вариант с базой данных, или, если это невозможно, используйте HTTP POST.

Используйте переменные сеанса или HTTP POST вместо HTTP GET.

Если серверы имеют общее доменное имя, вы можете использовать файл cookie.

Обновлено: файлы cookie просто скрывают идентификатор визуально, он все еще доступен. То же самое со скрытыми полями или с использованием POST, а не GET. Поэтому, если идентификатор достоверный и вы не хотите отправлять его по сети в незашифрованном виде, вам нужен другой подход.

Решением может быть шифрование идентификатора на сервере аутентификации ключом, который используется серверами. Другим решением может быть создание случайного GUID на сервере аутентификации, а затем позволить серверу аутентификации напрямую информировать другой сервер (через SSL), какому идентификатору соответствует GUID.

Вместо того, чтобы передавать его через строку запроса, вы должны создать скрытое поле формы с его значением, а затем опубликовать его на своей второй странице, которая затем может захватить опубликованное значение, и оно будет скрыто от пользователя.

Это звучит как непростая ситуация. Однако есть несколько вариантов, которые вы можете использовать, но все зависит от того, что делает ваше приложение.

Давайте назовем WebApp1 вашим сайтом аутентификации, а WebApp2 - вашим удаленным сайтом после аутентификации.

Может ли WebApp2 не вызывать WebApp1 за кулисами? (Услуги)

Проблема с передачей этого Guid между приложениями заключается в том, что он проходит через открытый текст, и, учитывая, что это идентификатор пользователя, если кому-то удастся его перехватить, он получит доступ к WebApp2 на всю жизнь. Независимо от того, передаете ли вы его в строке запроса или в переменной формы, он все равно уязвим.

Если вы не можете использовать WebApp2 для запроса WebApp1, вам следует рассмотреть возможность создания WebApp1 временного Guid, срок действия которого истекает. Это было бы намного безопаснее в долгосрочной перспективе, но, поскольку это чистый текст, все еще уязвимо для атак. Двум веб-приложениям также потребуется доступ к одному и тому же хранилищу данных.

В конечном счете, я думаю, что сайт AUthentication должен быть сервисом, который может использовать WebApp2. Пользователи должны входить в систему через WebApp2, который будет безопасно вызывать WebApp1 для аутентификации. Затем WebApp2 может управлять своим собственным сеансом.

Если вы не можете использовать файлы cookie, потому что это кросс-домен, зашифруйте их с помощью одноразового номера.

Установите общий секрет / ключ между двумя серверами; отправьте зашифрованную комбинацию GUID и одноразового номера на второй сервер. Расшифруйте, проверьте, что одноразовый номер еще не использовался (чтобы остановить ответные атаки), затем используйте незашифрованный GUID.

Если вы хотите быть более сложным, иметь веб-службу в app1, где она может проверять, действительно ли выдан одноразовый номер (на этом этапе вы направляетесь к WSTrust и решению для единого входа, которое обычно решает то, что вы пытаетесь сделать )

Даже с файлами cookie, поскольку они легко редактируются / подделываются, у вас должна быть какая-то форма проверки.

У вас есть два веб-приложения ASP.NET, и одно приложение ничего не делает, кроме аутентификации пользователя?

это похоже на работу для ....

Веб-сервисы!

Создайте новую веб-службу в приложении для аутентификации (это расширение .asmx) и добавьте единственный метод, который принимает пользователя, пароль и т. д. И возвращает информацию для аутентификации.

Затем импортируйте WSDL во второе приложение и вызовите первое приложение, как будто это метод. Это упростит ваш код и решит вашу проблему.

Пример:

AuthenticateUserService.asmx переходит в приложение аутентификации:

using System;
using System.Web;
using System.Web.Services;
using System.Web.Services.Protocols;

[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class AuthenticateUserService : System.Web.Services.WebService 
{   
    [WebMethod]
    public bool AuthenticateUser(string username, string passhash) 
    {
        // Fake authentication for the example
        return (username == "jon" && passhash == "SomeHashedValueOfFoobar");
    }
    
}

После настройки запустите основное приложение, щелкните проект правой кнопкой мыши и выберите «Добавить веб-ссылку».

Введите URL-адрес asmx в приложении проверки подлинности, и Visual Studio обнаружит его и создаст прокси-класс.

Как только это будет сделано, мы можем вызвать этот метод, как если бы он был локальным методом в нашем основном приложении:

protected void Page_Load(object sender, EventArgs e)
{
    // Now we can easily authenticate user in our code
    AuthenticateUserService authenticationProxy = 
         new AuthenticateUserService();
    bool isUserAuthenticated = 
         authenticationProxy.AuthenticateUser("jon", SomeHashMethod("foobar"));
}

Итак, что это на самом деле делает?

Это исключает клиента из процесса аутентификации.

Ваш текущий процесс:

• Клиент вводит учетные данные в AppA
• AppA перенаправляет клиента в AppB
• AppB перенаправляет клиента обратно в AppA, если учетные данные совпадают.

Заменяется вызовом SOAP на стороне сервера между AppA и AppB. Теперь это так:

• Клиент вводит учетные данные в AppA
• AppA спрашивает AppB, хороши ли они
• AppA предоставляет клиенту надлежащий контент.

перейдите к управлению сеансом или используйте HTTP-сообщение, как указано в сообщении выше.