22

我创建了许多生成/使用 JSON 数据的 Web 服务，并使用 OAuth2 和承载令牌保护它们，效果很好。

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

我可以看到两种方法：

  1. 服务的基于浏览器的客户端将使用 XHR Level2 和 HTML5 中的 Blob 和 Blob URL 方案来检索作为 Blob 的图像数据，使用 Blob URL 方案为 Blob 生成 URL，然后动态创建一个 img 标记来引用Blob URL。很多工作只是为了显示图像！

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

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

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

4

1 回答 1

14

我假设您正在使用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.
于 2012-12-05T18:42:11.293 回答