我创建了许多生成/使用JSON数据的Web服务，并且我使用OAuth2和Bearer Tokens保护它们，这可以正常工作。
现在我需要构建一个类似的Web服务来生成图像而不是JSON（所以JPEG / PNG数据）。为了保持一致性，我还想用OAuth2 / Bearer Tokens保护服务，但这样做会使服务更难以在希望使用＆lt; img＆gt;显示图像数据的基于浏览器的应用程序中使用。标签，因为＆lt; img＆gt;标签不会发送必要的Authorization: Bearer ...bearer-token... HTTP标头。
我可以看到两种方式：
服务的基于浏览器的客户端将使用XHR Level2和HTML5中的Blob和Blob URL方案将图像数据检索为Blob，使用Blob URL方案为Blob生成URL，然后动态创建一个引用Blob URl的img标签。很多工作只是为了显示图像！
修改OAuth2基础架构以生成除承载令牌之外的Http cookie。修改服务Authorirzation以接受授权：承载... OAuth2标头或cookie作为身份证明。 Cookie与承载令牌，httpOnly等具有相同的生命周期。基于浏览器的客户端可以依靠浏览器cookie支持来访问服务，可以通过＆lt; img＆gt;来提供图像数据。标签正常。易于使用的浏览器客户端，但非标准。对于不记名令牌或cookie，安全风险概况似乎相同。
我是否忽略了后一种方法的任何安全问题？
是否有使用OAuth2保护图像/媒体资源的替代方法？
答案 0 :(得分：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.