使用 OAuth2 承载令牌保护图像资源 [英] Protecting Image resources with OAuth2 Bearer Tokens
问题描述
我创建了许多生成/使用 JSON 数据的 Web 服务，并且我使用 OAuth2 和不记名令牌保护它们，这工作正常.
I've created a number of Web Services that produce/consume JSON data and I've protected them using OAuth2 and Bearer Tokens, which works fine.
但是现在我需要构建一个类似的 Web 服务来生成图像而不是 JSON(因此是 JPEG/PNG 数据).为了一致性，我还想使用 OAuth2/Bearer Tokens 保护服务，但这样做会使服务在希望使用 显示图像数据的基于浏览器的应用程序中使用起来更具挑战性.标签，因为 标签不会发送必要的 Authorization: Bearer ...bearer-token... HTTP 标头.
Now however I need to build a similar Web Service that produces images rather than JSON (so JPEG/PNG data). For consistency I would also like to protect the service with OAuth2/Bearer Tokens, but doing so would make the service more challenging to consume in browser based applications that wish to display the image data using the <img> tag, because the <img> tag will not send the necessary Authorization: Bearer ...bearer-token... HTTP header.
我可以看到两种方法:
服务的基于浏览器的客户端将使用 XHR Level2 以及来自 HTML5 的 Blob 和 Blob URL 方案来检索作为 Blob 的图像数据，使用 Blob URL 方案为 Blob 生成一个 URL，然后动态创建一个引用 Blob URl 的 img 标签.很多工作只是为了显示图像！
Browser based clients of the Service would use XHR Level2 and the Blob and Blob URL schemes from HTML5 to retrieve the image data as a Blob, use the Blob URL scheme to generate a URL for the Blob and then dynamically create an img tag that refers to the Blob URl. A lot of work just to display an image!
修改 OAuth2 基础设施以生成一个 Http cookie 除了承载令牌.修改服务 Authorirzation 以接受 Authorization: Bearer ... OAuth2 标头或 cookie 作为身份证明.Cookie 与承载令牌、httpOnly 等具有相同的生命周期.基于浏览器的客户端可以仅依赖浏览器 cookie 支持来访问服务，可以通过 来访问图像数据.正常标记.易于用于浏览器客户端，但非标准.不记名令牌或 cookie 的安全风险状况似乎相同.
Modify the OAuth2 infrastructure to generate a Http cookie in addition to the Bearer Token. Modify the service Authorirzation to accept EITHER the Authorization: Bearer ... OAuth2 header OR the cookie as proof of identity. Cookie to have same lifetime as bearer token, httpOnly etc. Browser based clients can just rely on browser cookie support to get access to service, can deference image data via <img> tag as normal. Easy to use for browser clients, but non-standard. Security risk profile seems the same for either bearer token or cookie.
我是否忽略了后一种方法的任何安全问题?
Am I overlooking any security issues with the latter approach?
是否有其他方法可以使用 OAuth2 保护图像/媒体资源?
Are there any alternative approaches for protecting image/media resources with OAuth2?
推荐答案
我假设您正在使用 基于用户代理的应用程序 配置文件来获取不记名令牌到浏览器基础应用程序中.
I assume you are using the user-agent-based application profile in terms of getting a bearer token into the browser base app.
OAuth 承载令牌规范支持将令牌作为查询参数发送?access_token=mF_9.B5f-4.1JqM.浏览器中的 javascript 可以将令牌作为查询参数添加到您的 img 链接中.
The OAuth Bearer Token spec supports sending the token as a query parameter ?access_token=mF_9.B5f-4.1JqM. The javascript in your browser could add the token as a query parameter to your img links.
这将更加基于标准，但是您将不得不担心 access_token 值会在日志中泄漏等.我认为安全权衡将真正取决于这些承载的范围令牌，以及保护这些图像的重要性.
This would be more standards based, but then you would have to worry about the access_token value leaking out in logs, etc. I think the security trade offs would really depend on the scope of those bearer tokens, and how important these images are to protect.
我认为开放您的 OAuth 基础架构以接受 cookie 可能会让您面临新的攻击媒介.RFC 6750 特别标注了CSRF攻击的风险
I think opening up your OAuth infrastructure to accept cookies could open you up to new attack vectors. RFC 6750 specifically calls out the risk of CSRF attacks
Implementations that do store bearer tokens in cookies MUST take precautions
against cross-site request forgery.
这篇关于使用 OAuth2 承载令牌保护图像资源的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
