Объединение проверки подлинности форм и OAUTH

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

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

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

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

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

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

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

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

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

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

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

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


oauth forms-authentication thinktecture-ident-model
person Peter Wone    schedule 05.02.2015    source источник
comment
Есть ли какая-то причина, по которой вы не можете просто использовать более короткий срок службы токена для обоих токенов? Когда срок действия первого истечет, просто потребуйте повторной аутентификации и либо отзовите токен с более длительным сроком службы, либо просто замените его.   -  person mpowered    schedule 17.02.2015
comment
То, что вы ищете, это конфигурация истечения срока действия токена аутентификации. однако в вашем вопросе очень мало подробностей о том, что вы делаете и чего вы пытаетесь достичь. почему вы использовали localStorage (на стороне клиента) для токена OAUTH, а также формирует аутентификацию (на стороне сервера).   -  person Bishoy    schedule 18.02.2015

Ответы (1)


arrow_upward
0
arrow_downward

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

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

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

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

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

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

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

person Peter Wone    schedule 20.02.2015