Идентификация AspNet в гибридном контроллере MVC/Web Api

У меня есть сайт, использующий как mvc, так и web-api-контроллеры и идентификатор aspnet. Я использовал шаблон VS2013 SPA с двумя контроллерами mvc и web api в качестве отправной точки.

Вот мой сценарий:

Пользователь регистрируется с использованием контроллера mvc и возвращает файл cookie с авторизацией.

Следующая страница обслуживается с использованием контроллера mvc, прошедшего проверку подлинности. Эта страница использует нокаут и делает ajax пост-вызов контроллеру веб-api, который аутентифицируется нажатием кнопки (Save). Для контроллера web api требуется заголовок проверки подлинности с помощью Bearer --token -.

Мой вопрос в том, как другие обрабатывают эти "два" подхода к аутентификации. Я создал конечную точку на контроллере mvc, которая аутентифицирована и возвращает токен-носитель на основе текущего принципала. Я могу использовать этот токен для успешной публикации в веб-API конечной точке.

Логика javascript, которую я создаю, немного... запутанная. Он проверяет, находится ли токен доступа в хранилище сеансов, если это делает вызов ajax. Если нет, вызовите конечную точку доступа token, а затем вызовите конечную точку web api (используя кучу обратных вызовов для обработки обещаний Ajax, fail, ect).

Как другие обрабатывали сценарий, в котором вам нужны как cookie файл cookie, так и маркер-носитель, поэтому каждая страница "mvc" аутентифицирована, а конечная точка веб-api, вызываемая страницами, проходит аутентификацию. Что вы будете делать, если токен-носитель истечет до истечения срока действия файла cookie.

Сообщите мне, если я не понял или вам нужна дополнительная информация.

Изменить

Я наткнулся на это, Совместное использование токенов-носителей и проверки файлов cookie Он по-прежнему не отвечает на мой вопрос, поскольку у меня он уже настроен, поэтому mvc принимает cookie auth, а web api принимает только токен. Я чувствую, что это должна быть проблема, которая уже решена, но, возможно, я ошибаюсь.

Ответ 1

Я думаю, вы в основном столкнулись с основной проблемой с помощью OAuth2.0. OAuth2.0 - это только протокол авторизации. Вам нужна модель безопасности, которая поддерживает как аутентификацию, так и авторизацию.

Представляем OpenId Connect

OpenId Connect - это уровень аутентификации, построенный на уровне авторизации OAuth2.0. Он обеспечивает простой способ проверки конечного пользователя на основе аутентификации, выполняемой на фоновом сервере/службе. Кроме того, он может передать базовый профиль о пользователе в RESTful HTTP API для авторизации с использованием JSON.

"OpenId Connect позволяет использовать целый ряд клиентов, включая веб- мобильных и JavaScript-клиентов, запрашивать и получать информацию об аутентифицированных сеансах и конечных пользователях. Набор спецификаций расширяемый, поддерживающий дополнительные функции, такие как шифрование идентификационные данные, обнаружение поставщиков OpenID и управление сеансами". - Wikipedia

Для .NET существует пакет Nuget для компонента Identity Server, называемый IdentityServer3. Существует довольно углубленное начало учебника о том, как получить простой MVC/Web-API, работающий с IdentityServer3.

Веб-приложения против веб-API и Cookies против токенов

Обычно веб-приложения являются традиционными серверными приложениями, использующими аутентификацию на основе файлов cookie.
С другой стороны, веб-API представляют для нас новую породу приложений, как правило, одностраничных приложений (таких как Angular, Ember, Backbone и т.д.) или собственных мобильных приложений (таких как iOS, Android, и т.д.), которые потребляют API (написанные в Node, Ruby, ASP.NET или даже их сочетание) и будут пользоваться аутентификацией на основе токенов.

Вы можете прочитать эти статьи для большего контекста: Cookies vs Tokens. Получение прав с помощью Angular.JS и 10 вещей, которые вы должны знать о токенах.

Проверка подлинности на основе cookie реализуется каждой веб-платформой по-разному, но в конце дня все они устанавливают некоторый файл cookie (привязанный к сеансу на сервере), который представляет собой "аутентифицированный пользователь". По каждому запросу этот cookie отправляется и сеанс десериализуется из некоторого хранилища (в памяти, если это один сервер или некоторое постоянное хранилище, если это ферма серверов).
Аутентификация на основе токена реализуется путем создания токена, когда пользователь аутентифицируется, а затем устанавливает этот токен в заголовке авторизации каждого последующего запроса в ваш API. Вы хотите, чтобы этот токен был чем-то стандартным, например, JSON Web Tokens, так как вы найдете библиотеки на большинстве платформ, и вы не хотите делать свой собственный крипто.
Для обоих подходов вы можете получить одинаковое количество информации от пользователя. Это контролируется параметром области, отправленным в запросе на вход.
Вы можете смешивать аутентификацию на основе токена с аутентификацией на основе файлов cookie. Учтите, что файлы cookie будут работать очень хорошо, если веб-приложение и API будут обслуживаться из одного домена, поэтому вам может не понадобиться аутентификация на основе токенов. Если вы хотите вызывать свои API из JavaScript (вместо использования существующего файла cookie), то вам нужно установить id_token на свою веб-страницу. Один из способов сделать это - установить на своей макете/главной странице что-то вроде window.token = <% = id_token% > ; и затем вы получите его из любого места в своем JavaScript-коде.

PS Это отличный видео по теме под названием "Объединение аутентификации и делегированного доступа к API для мобильных устройств, Интернета и рабочего стола с помощью OpenID Connect и OAuth2 от Доминика Байера". Это должно помочь пролить свет на ограничения OAuth2.0 и то, как OpenId Connect пытается их решить.

Ответ 2

Мне удалось обойти эту проблему, используя куки и обновить токен.

Вот как это делается,

Зашифровать и сохранить токен доступа и обновить токен в файле cookie.
Подтвердите дату истечения срока годности перед вызовом веб-api.
Если токен истек, получите новый токен, используя токен обновления/очистить пользовательский файл cookie и выйдите из него.

Я не пробовал его в шаблоне SPA VS2013. Но, как я вижу, вы можете использовать второй шаг для проверки токена, и если он истек, вызовите точку окончания контроллера mvc, чтобы получить новый токен доступа.