使用 OAuth2 Bearer Tokens 保护图像资源

Question

我创建了许多生成/使用 JSON 数据的 Web 服务，并使用 OAuth2 和 Bearer Tokens 保护它们，这些都可以正常工作。

但是现在我需要构建一个类似的 Web 服务来生成图像而不是 JSON（所以 JPEG/PNG 数据）。为了保持一致性，我还想使用 OAuth2/Bearer 令牌保护服务，但这样做会使服务在希望使用 标签显示图像数据的基于浏览器的应用程序中更具挑战性，因为 标签不会发送必要的Authorization: Bearer ...bearer-token... HTTP 标头。

我可以看到两种解决方法：

1. 服务的基于浏览器的客户端将使用 XHR Level2 和 HTML5 中的 Blob 和 Blob URL 方案将图像数据检索为 Blob，使用 Blob URL 方案为 Blob 生成 URL，然后动态创建一个指向 Blob URl 的 img 标签。仅显示图像就需要做很多工作！

2. 修改 OAuth2 基础结构以生成除承载令牌之外的 Http cookie。修改服务 Authorirzation 以接受 Authorization: Bearer ... OAuth2 标头或 cookie 作为身份证明。 Cookie 与承载令牌、httpOnly 等具有相同的生命周期。基于浏览器的客户端可以仅依靠浏览器 cookie 支持来访问服务，可以像往常一样通过 标签尊重图像数据。易于浏览器客户端使用，但非标准。不记名令牌或 cookie 的安全风险概况似乎相同。

我是否忽略了后一种方法的任何安全问题？

是否有任何替代方法可以使用 OAuth2 保护图像/媒体资源？

Answer 1

我假设您使用user-agent-based application 配置文件将不记名令牌获取到浏览器基础应用程序中。

OAuth Bearer Token 规范支持将令牌作为查询参数?access_token=mF_9.B5f-4.1JqM 发送。您浏览器中的 javascript 可以将令牌作为查询参数添加到您的 img 链接。

这将基于更多标准，但是您将不得不担心 access_token 值会在日志中泄漏等。我认为安全性权衡实际上取决于这些不记名令牌的范围以及重要性这些图像是为了保护。

我认为开放您的 OAuth 基础架构以接受 cookie 可能会使您面临新的攻击媒介。 RFC 6750 明确指出了 CSRF 攻击的风险

 Implementations that do store bearer tokens in cookies MUST take precautions
 against cross-site request forgery.