Приложения для браузера и токены аутентификации

Question

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

У нас есть этот ASP.NET Web API 2, который защищен с помощью токенов, выпущенных IdSvr3. Все идет нормально. Работает с собственными клиентами и серверными приложениями.

Теперь в браузер ... Посмотрите на образец, например JavaScriptImplicitClient, который использует библиотеку oidc-client-js для извлечения токенов с использованием неявного потока. Токен хранится в браузере, который доступен с помощью JavaScript и там открыт для атак XSS. Чтобы избежать этого, предложения указывают на сохранение токена в файле cookie и затем настройку механизма предотвращения атак CSRF.

Кажется простым, но что устанавливает этот файл cookie?

• Действительно ли это IdSvr? Не имеет смысла, так как это API, которому нужен файл cookie.

• Это API? Во время входа Implicit Flow пользователь перенаправляется в API, который устанавливает сеанс, а затем перенаправляет пользователя обратно в SPA с заголовком Set-Cookie? Затем файл cookie будет присутствовать в API при последующих запросах.

• Третье решение? Некоторые упоминают создание второго «API», который проксирует запросы к «реальному» API, но устанавливает заголовок auth.

Есть ли у вас образцы такой установки, или вы можете дать некоторые подсказки о том, как вы это сделаете?

Answer 1

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

Я сделал сравнение плюсов и минусов нескольких подходов к хранению токенов доступа в приложении веб-браузера, которые вы можете check in this answer to a related question.

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

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