Stworzyłem wiele usług WWW, które produkują / konsumują dane JSON i chroniłem je za pomocą OAuth2 i Bearer Tokens, co działa dobrze.

Teraz jednak muszę zbudować podobną usługę internetową, która tworzy obrazy, a nie JSON (czyli dane JPEG / PNG). Aby zachować spójność, chciałbym również chronić usługę za pomocą tokenów OAuth2 / Bearer, ale uczyniłoby to usługę trudniejszą do wykorzystania w aplikacjach opartych na przeglądarce, które chcą wyświetlać dane obrazu za pomocą tagu <img>, ponieważ <img> tag nie wyśle ​​niezbędnychAuthorization: Bearer ...bearer-token... Nagłówek HTTP.

Widzę to na dwa sposoby:

Klienci usługi korzystający z przeglądarki korzystaliby z XHR Level2 i schematów URL Blob i Blob z HTML5, aby pobrać dane obrazu jako Blob, użyj schematu URL Blob, aby wygenerować URL dla Blob, a następnie dynamicznie utwórz tag img, który odnosi się do blob URl. Dużo pracy, aby wyświetlić obraz!

Zmodyfikuj infrastrukturę OAuth2, aby wygenerować plik cookie Http oprócz tokena okaziciela. Zmodyfikuj usługę Authorirzation, aby zaakceptować EITHER Authorization: Bearer ... nagłówek OAuth2 LUB cookie jako dowód tożsamości. Cookie ma taki sam czas życia jak token na okaziciela, httpOnly itp. Klienci korzystający z przeglądarki mogą polegać na obsłudze plików cookie przeglądarki, aby uzyskać dostęp do usługi, mogą normalnie traktować dane obrazu za pomocą tagu <img>. Łatwy w użyciu dla klientów przeglądarek, ale niestandardowy. Profil ryzyka bezpieczeństwa wydaje się taki sam dla tokena na okaziciela lub pliku cookie.

Czy pomijam wszelkie problemy związane z bezpieczeństwem w tym drugim podejściu?

Czy istnieją alternatywne podejścia do ochrony zasobów obrazu / multimediów za pomocą OAuth2?