Реализовать аутентификацию без сохранения состояния с помощью аудио / видео HTML5 (и простых изображений), возможно ли это?

Question

У нас есть API в стиле REST и мы стараемся следовать принципам REST как можно ближе, поэтому, конечно, это также относится и к безгражданству.

Хотя большая часть нашего бэкэнда действительно не имеет состояния, есть одна вещь, которую, кажется, невозможно достичь, а именно аутентификация не связанных с API статических ресурсов. Я понимаю, что существуют средства для достижения аутентификации без сохранения состояния с использованием некоторых подходов на основе токенов (например, JWT). Но это требует установки некоторых заголовков или передачи учетных данных в теле сообщения запросов.

Это не будет проблемой, если нужно защитить только запросы API, поскольку мы легко можем изменить XHR или получить запросы соответствующим образом.

Но проблема в том, что нам также необходимо защитить статические ресурсы, такие как изображения и аудио / видео файлы. Для изображений я мог бы загрузить их через XHR / fetch, хотя это уже довольно громоздко по сравнению с использованием простого тега изображения.

Но как только дело доходит до видео / аудио в формате html5, я не нашел способа добиться этого, возможно ли это вообще?

В настоящее время мы просто используем защищенный файл cookie httpOnly, поэтому в этом случае не возникает проблем ни с изображениями, ни с аудио. Может ли использование файла cookie (имеющего JWT-подобную полезную нагрузку), сгенерированного клиентом, быть решением? Конечно, это может открыть еще одну потенциальную проблему безопасности, поскольку теперь - в случае нарушения XSS - файл cookie и его информация могут быть украдены, что невозможно с помощью файла cookie httponly.

Есть ли какие-либо идеи для достижения чистой аутентификации без сохранения состояния, которая также работает для изображений и аудио или видео html5 (и это также не менее безопасно)?

PS: Базовая аутентификация HTTP является , а не опцией по различным причинам.

Answer 1

Нет идей? Хммм. Хорошо, так что возможно Я могу ответить на свой вопрос ...

Потенциальным решением было бы использовать что-то вроде JWT, но все же использовать печенье как транспортный механизм. Таким образом, токен генерируется на сервер, и устанавливается через cookie, как это было раньше с традиционным сеансовым cookie. Похоже, я мог бы иметь "лучшее из обоих миры "с таким подходом:

• У клиента все еще нет средств для доступа к содержимому куки, и, следовательно, не нужно ничего знать об авторизации. Единственное, что есть у клиента знать - это концепция аутентификации, т.е. запрашивать у пользователя учетные данные и отправка их на сервер, как только 401 вернулся.

• Сервер теперь свободен от любого управления сессиями, все что он должен делать проверяет токен.

• И, самое главное: это будет работать не только для запросов, где я могу манипулировать заголовком и / или телом сообщения (например, с помощью XHR / fetch), но и для любого типа статического ресурса, включая изображения и html5. аудио и видео

Это звучит как хорошее решение? Проголосуйте за этот ответ, если считаете, что это так! Спасибо.