Ich habe eine Reihe von Webdiensten erstellt, die JSON-Daten erstellen / verarbeiten, und diese mit OAuth2- und Bearer-Tokens geschützt, was problemlos funktioniert.

Jetzt muss ich jedoch einen ähnlichen Webdienst erstellen, der Bilder anstelle von JSON erzeugt (also JPEG / PNG-Daten). Aus Gründen der Konsistenz möchte ich den Dienst auch mit OAuth2 / Bearer-Tokens schützen, dies würde jedoch die Verwendung des Dienstes in browserbasierten Anwendungen erschweren, die die Bilddaten mit dem <img> -Tag anzeigen möchten, da das <img> Tag wird nicht die notwendigen sendenAuthorization: Bearer ...bearer-token... HTTP-Header.

Ich kann zwei Wege erkennen:

Browserbasierte Clients des Dienstes verwenden XHR Level2 und die Blob- und Blob-URL-Schemata aus HTML5, um die Bilddaten als Blob abzurufen. Verwenden Sie das Blob-URL-Schema, um eine URL für den Blob zu generieren und erstellen Sie dann dynamisch ein img-Tag, das auf verweist der Blob URl. Viel Arbeit, nur um ein Bild anzuzeigen!

Ändern Sie die OAuth2-Infrastruktur, um zusätzlich zum Inhaber-Token ein HTTP-Cookie zu generieren. Ändern Sie die Service-Autorisierung, um entweder die Autorisierung: Inhaber ... OAuth2-Header oder den Cookie als Identitätsnachweis zu akzeptieren. Cookies haben die gleiche Lebensdauer wie Inhaber-Token, httpOnly usw. Browserbasierte Clients können sich nur auf die Unterstützung von Browser-Cookies verlassen, um Zugriff auf den Dienst zu erhalten. Sie können Bilddaten über das <img> -Tag wie gewohnt zurückstellen. Einfach für Browser-Clients zu verwenden, aber nicht Standard. Das Sicherheitsrisikoprofil scheint für Inhaber-Token oder Cookie gleich zu sein.

Vergesse ich bei letzterem Ansatz irgendwelche Sicherheitsprobleme?

Gibt es alternative Ansätze zum Schutz von Bild- / Medienressourcen mit OAuth2?