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

Question

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

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

我可以看到两种方式:

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

2. 修改OAuth2基础结构以生成除承载令牌之外的Http cookie.修改服务Authorirzation以接受授权:承载... OAuth2标头或cookie作为身份证明.Cookie与承载令牌,httpOnly等具有相同的生命周期.基于浏览器的客户端可以依靠浏览器cookie支持来访问服务,可以正常地通过<img>标签来引用图像数据.易于使用的浏览器客户端,但非标准.对于承载令牌或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.