Аутентификация мостовых форм и OAUTH

Question

Нетрудно изменить процесс входа в систему аутентификации форм, чтобы в дополнение к обычной проверке подлинности объект WebClient выполнял базовую аутентификацию с URL-адресом api/token, обслуживаемым веб-Api DAL, настроенным с помощью Thinktecture IdentityModel , Затем возвращаемый токен сеанса может быть сохранен в словаре сеанса для последующего использования при вызове DAL.

Проблема в том, что эти токены имеют разные сроки жизни.

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

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

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

---

Немного фона, так как некоторые люди не поняли, о чем я прошу.

Там большая уродливая старая школа ASP.NET веб-приложение, которое использует на основе форм безопасности

Я только что добавили новый материал в виде отдельного приложения DAL, который использует Thinktecture IdentityModel. Этот DAL используется двумя приложениями, приложением ASP.NET и Durandal SPA.

Они используют одну и ту же базу данных для проверки учетных данных, поэтому они имеют одинаковое пространство идентичности.

Я изменил процесс входа в старый приложение, чтобы он также предоставлял учетные данные и получал токен сеанса из ThinkTecture IdentityModel. Этот токен помещается в коллекцию сеанса, который будет отображаться всякий раз, когда старое приложение вызывает DAL.

Если запустить старое приложение, проверку подлинности, делать вещи и закрыть браузер, а потом снова открыть браузер, у вас есть вход в приложение ASP.NET без Войти происходящий так что нет никакой возможности создать маркер сеанса. Это проблема. Мне нужно, чтобы оба токена имели одинаковый жизненный цикл.

---

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

Answer 1

На сервере я знаю идентификатор пользователя, как при создании токена сеанса, так и позже, когда сеанс ASP.NET воссоздается без него.

Мне нужен серверный эквивалент файла cookie. Быстрый поиск «cookie на стороне сервера» вернул пару статей, один из которых я, по-видимому, написал в 1999 году, и все это сводится к «использованию базы данных».

Итак ... Я мог бы использовать базу данных. У нас есть пользовательская таблица, я мог бы добавить столбец. Или я мог бы создать другую таблицу с тремя столбцами: UID, SessionToken и CreatedAt.

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

---

В результате я использовал вариант. В моем конкретном случае, с UID, учетные данные могут быть получены из таблицы пользователей. Поэтому я помещаю токен и время создания в сеанс, и в противном случае выполнялось, как указано выше. Когда сеанс не содержит времени истечения токена или токен истек, я беру учетные данные и запрашиваю токен, а затем обновляю токен и истечение срока действия.

Все это завернуто в обработчик исключений, который возвращает фиктивный (недействительный) токен, результатом которого является поведение, идентичное токенам одинаковой долговечности.

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