Web API 2 OWIN Назначение маркера носителя для cookie?

Я пытаюсь понять новый процесс аутентификации идентификатора новичка OWIN в шаблоне приложения одиночной страницы в MVC 5. Пожалуйста, исправьте меня, если я ошибаюсь, для потока аутентификации пароля пользователя OAuth аутентификация маркера на предъявителя работает, проверяя http заголовок запроса авторизации для кода токена доступа, чтобы проверить, проверен ли запрос, он не полагается на файл cookie для проверки подлинности конкретного запроса.

В соответствии с этим сообщением:

Аутентификация маркера на предъявителя OWIN с помощью Web API Пример

public override async Task GrantResourceOwnerCredentials(OAuthGrantResourceOwnerCredentialsContext context)
{
    using (IdentityManager identityManager = _identityManagerFactory.CreateStoreManager())
    {
        if (!await identityManager.Passwords.CheckPasswordAsync(context.UserName, context.Password))
        {
            context.SetError("invalid_grant", "The user name or password is incorrect.");
            return;
        }

        string userId = await identityManager.Logins.GetUserIdForLocalLoginAsync(context.UserName);
        IEnumerable<Claim> claims = await GetClaimsAsync(identityManager, userId);
        ClaimsIdentity oAuthIdentity = CreateIdentity(identityManager, claims,
            context.Options.AuthenticationType);
        ClaimsIdentity cookiesIdentity = CreateIdentity(identityManager, claims,
            _cookieOptions.AuthenticationType);
        AuthenticationProperties properties = await CreatePropertiesAsync(identityManager, userId);
        AuthenticationTicket ticket = new AuthenticationTicket(oAuthIdentity, properties);
        context.Validated(ticket);
        context.Request.Context.Authentication.SignIn(cookiesIdentity);
    }
}

Функция GrantReourceOwnerCredentials не только составляет билет с этой строкой: context.Validated(ticket); но он также составляет идентификатор файла cookie и устанавливает его в файл cookie с помощью этой строки: context.Request.Context.Authentication.SignIn(cookieIdentity);

Итак, мои вопросы: какова цель cookie в этой функции? Должен ли AuthenticationTicket быть достаточно хорошим для целей аутентификации?

Ответ 1

В шаблоне SPA на самом деле существуют два отдельных механизма аутентификации, позволяющие проверять подлинность cookie и аутентификацию токена. Это позволяет аутентифицировать действия MVC и Web API, но требует некоторой дополнительной настройки.

Если вы посмотрите в методе WebApiConfig.Register, вы увидите эту строку кода:

    config.SuppressDefaultHostAuthentication();

Это указывает веб-API игнорировать аутентификацию cookie, что позволяет избежать множества проблем, которые объясняются в ссылка, которую вы разместили в своем вопросе:

"... шаблон SPA позволяет использовать промежуточное программное обеспечение cookie приложения как активный режим, чтобы включить другие сценарии, такие как аутентификация MVC. Таким образом, веб-интерфейс API будет по-прежнему аутентифицирован, если запрос имеет cookie сеанса, но без токена-носителя. а не то, что вы хотите, так как вы были бы почтенными для атак CSRF для ваших API-интерфейсов. Еще одно негативное влияние заключается в том, что если запрос несанкционирован, оба компонента промежуточного программного обеспечения будут применять к ним проблемы. Средство промежуточного программного обеспечения cookie изменит ответ 401 на 302 для перенаправления на страница входа в систему. Это также не то, что вы хотите в запросе веб-API."

Итак, теперь с вызовом config.SuppressDefaultHostAuthentication(), вызовы Web API, требующие авторизации, будут игнорировать куки файл, который автоматически отправляется вместе с запросом и ищет заголовок авторизации, который начинается с "Bearer". Контроллеры MVC будут продолжать использовать аутентификацию cookie и не знают механизм аутентификации маркера, поскольку он не очень подходит для проверки подлинности веб-страницы.

Ответ 2

Существование файла cookie также оставило меня озадаченным, поскольку он явно не нужен в сценарии аутентификации маркера на предъявителя... В this post автор анализирует шаблон отдельных учетных записей и имеет следующее сообщение о файле cookie:

Метод также устанавливает cookie приложения. Я не вижу достаточной причины для этого.

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

Тот факт, что в качестве полезной нагрузки для аутентификации JSON установлено также дополнительное (ненужное) незашифрованное свойство (идентификатор пользователя), в дополнение к зашифрованному билету, похоже, поддерживает эту теорию:

var properties = CreateProperties(user.UserName);
var ticket = new AuthenticationTicket(oAuthIdentity, properties);

Похоже, авторы шаблона хотели предоставить несколько полезных примеров, а не минимальный минимум, необходимый для достижения аутентификации маркера на предъявителя. Это также упоминается в связанном сообщении выше.

Ответ 3

У печенья есть одна важная цель. Его значение содержит токен-носитель, который может быть извлечен на стороне клиента javascript на ваших страницах. Это означает, что если пользователь нажимает F5 или обновляет страницу, файл cookie, как правило, сохраняется. Затем ваш клиентский javascript может захватить токен-носитель из файла cookie при перезагрузке страницы.