Отдельное истечение срока действия cookie для Identity Server и ASP.NET Core Identity - PullRequest
Новая
       10

Отдельное истечение срока действия cookie для Identity Server и ASP.NET Core Identity

0 голосов
/ 29 октября 2018

В настоящее время у меня есть работающий экземпляр Identity Server 4, который используется для защиты API, к которому обращаются нативные мобильные приложения (iOS и Android). Для этих мобильных приложений мы требуем, чтобы процесс выхода осуществлялся при удалении токенов, полученных с Identity Server (например, без обратной передачи на Identity Server).

Проблема, с которой мы сталкиваемся в настоящее время в связи с вышеизложенным, заключается в том, что, когда пользователь выходит из системы и мы сразу же пытаемся войти в систему, браузер «думает», что пользователь уже аутентифицирован из-за наличия файла cookie аутентификации Identity Server из первый вход.

Наша конфигурация Identity Server в настоящее время использует Asp.Net Core Identity и Quickstart UI , и мне удалось исправить эту ситуацию, изменив время истечения срока действия файла cookie ASP.NET Core Identity на 1 секунду. следующим образом: 

services.AddIdentity<UserEntity, ApplicationRoleEntity>()
.AddEntityFrameworkStores<UserContext>()
.AddDefaultTokenProviders();

services.ConfigureApplicationCookie(options =>
{
    options.ExpireTimeSpan = TimeSpan.FromSeconds(1);
});

Поскольку срок действия cookie-файла Auth истекает через секунду, когда пользователь выходит из собственного приложения и сразу же пытается войти снова, ему предоставляется интерфейс входа в систему Identity Server, и вход в систему работает, как и ожидалось.

Однако приведенные выше изменения, очевидно, влияют на использование самого пользовательского интерфейса Quickstart при использовании в браузере (а не при входе в систему), как, например, когда срок действия файла cookie истекает через секунду, пользователь сразу выходит из быстрого запустить приложение.

Чего я надеюсь добиться, так это, возможно, отделить cookie-файл ASP.Net Core Identity от файла Auth Cookie, используемого Identity Server - в основном, чтобы собственное приложение могло продолжать работать как есть (с файлом cookie Auth Identity Server, который является недействительным, сразу же становится недействительным после входа в систему, потому что на данный момент у нас есть токены), но пользователь может использовать интерфейс быстрого запуска в браузере без истечения срока действия файла cookie для этого приложения.

Обновление от 30 октября 2018 г. - предлагаемое решение

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

Теперь у меня есть решение, которое, кажется, работает для моих требований, которое включает создание класса CookieEvents для файла cookie приложения, используемого ASP.NET Core Identity и Identity Server. Это настроено следующим образом при запуске. 

services.ConfigureApplicationCookie(options =>
{
    options.EventsType = typeof(CookieEvents);
});

В классе CookieEvents я добавляю новый элемент в словарь AuthenticationItems.Items, когда происходит событие входа для конечной точки авторизации. При будущих запросах на вход в конечную точку авторизации из собственного мобильного приложения (которое я идентифицирую, используя client_id из строки запроса в ValidatePrincipal of CookieEvents), я затем проверяю наличие элемента, добавленного в cookie, и, если он найден, основной отклонено, что вынуждает пользователя снова пройти процесс входа в систему, даже если браузер, используемый для входа в систему, имеет действительный файл cookie аутентификации. Пример класса CookieEvents ниже (частные методы удалены для краткости) 

public override Task SigningIn(CookieSigningInContext context)
{
    if (IsRequestToAuthorizeEndpoint(context.Request) &&
    !context.Properties.Items.ContainsKey("signed-in"))
    {
        context.Properties.Items.Add("signed-in", "true");
    }

    return base.SigningIn(context);
}

public override Task ValidatePrincipal(CookieValidatePrincipalContext 
context)
{
    if (IsNativeAppSignIn(context.Request) &&
        context.Properties.Items.ContainsKey("signed-in"))
    {
        context.RejectPrincipal();
        return Task.CompletedTask;
    }

    return base.ValidatePrincipal(context);
}

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

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

...