мы создали несколько веб-сервисов, которые производят / потребляют данные JSON, и яМы защитили их, используя OAuth2 и Bearer Tokens, которые отлично работают.

Однако теперь мне нужно создать аналогичный веб-сервис, который генерирует изображения, а не JSON (то есть данные JPEG / PNG). Для обеспечения согласованности я также хотел бы защитить службу с помощью маркеров OAuth2 / Bearer, но это усложнило бы использование службы в браузерных приложениях, которые хотят отображать данные изображения с помощью <IMG> тег, потому что <IMG> тег не отправит необходимыйAuthorization: Bearer ...bearer-token... HTTP заголовок.

Я могу видеть два пути вокруг этого:

Клиенты Сервиса на основе браузера будут использовать схемы XHR Level2 и URL-адреса BLOB-объектов и BLOB-объектов из HTML5 для извлечения данных изображения в виде BLOB-объектов, использовать схему URL-адресов Blob-объектов для создания URL-адреса для BLOB-объектов и затем динамически создавать тег img, который ссылается на Blob URl. Много работы только для отображения изображения!

Измените инфраструктуру OAuth2, чтобы в дополнение к токену носителя был создан файл cookie Http. Измените сервис Авторизация так, чтобы он принимал ЛИБО Авторизация: заголовок OAuth2 на предъявителя ... ИЛИ cookie в качестве подтверждения личности. Куки имеют тот же срок жизни, что и токен на предъявителя, httpOnly и т. Д. Клиенты на основе браузера могут просто полагаться на поддержку куки-файлов браузера для получения доступа к сервису, могут задерживать данные изображения через <IMG> пометить как обычно. Простой в использовании для клиентов браузера, но нестандартный. Профиль риска безопасности выглядит одинаково как для токена на предъявителя, так и для cookie.

Я пропускаю какие-либо проблемы безопасности с последним подходом?

Существуют ли альтернативные подходы для защиты графических / медиаресурсов с помощью OAuth2?