使用OAuth2承载令牌保护图像资源

我已经创建了许多生成/使用JSON数据的Web服务,并且我使用OAuth2和Bearer Tokens保护它们,这可以正常工作 .

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

我可以看到两种方式:

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

  • 修改OAuth2基础架构以生成除承载令牌之外的Http cookie . 修改服务Authorirzation以接受授权:承载... OAuth2标头或cookie作为身份证明 . Cookie与承载令牌,httpOnly等具有相同的生命周期 . 基于浏览器的客户端可以依靠浏览器cookie支持来访问服务,可以正常地通过<img>标签来提供图像数据 . 易于使用的浏览器客户端,但非标准 . 对于不记名令牌或cookie,安全风险概况似乎相同 .

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

是否有使用OAuth2保护图像/媒体资源的替代方法?

回答(1)

2 years ago

我假设您正在使用 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.