Я создал несколько веб-сервисов, которые производят/потребляют данные JSON, и я защитил их, используя OAuth2 и Toker Tokens, который отлично работает.
Теперь, однако, мне нужно создать аналогичную веб-службу, которая создает изображения, а не JSON (поэтому данные JPEG/PNG). Для согласованности я также хотел бы защитить службу с помощью токенов OAuth2/Bearer, но это сделало бы услугу более сложной для использования в приложениях на основе браузера, которые хотят отображать данные изображения, используя <img> тег, поскольку <img> тег не отправит необходимый HTTP-заголовок Authorization: Bearer ...bearer-token....
Я вижу два пути вокруг этого:
-
Клиенты на основе браузера Службы будут использовать XHR Level2 и схемы URL Blob и Blob из HTML5 для извлечения данных изображения в виде Blob, используйте схему URL-адреса Blob для создания URL-адреса для Blob, а затем динамически создавайте тег img, который ссылается на Blob URl. Много работы просто для отображения изображения!
-
Измените инфраструктуру OAuth2 для создания Http файла cookie в дополнение к Token Token. Измените авторизацию службы, чтобы принять ее как удостоверение: несущий... OAuth2 или файл cookie как подтверждение личности. Cookie имеет такую же продолжительность жизни, как токен-носитель, httpOnly и т.д. Клиенты на основе браузера могут просто полагаться на поддержку файлов cookie браузера, чтобы получить доступ к сервису, могут передавать данные изображения через <img> как обычно. Простота использования для браузеров, но нестандартная. Профиль риска безопасности кажется одинаковым для токена-носителя или файла cookie.
Могу ли я игнорировать любые проблемы безопасности с последним подходом?
Существуют ли альтернативные подходы для защиты ресурсов изображения/мультимедиа с помощью OAuth2?
