在问题中,替换
scope
为state
。由于有一个基于错误问题的答案,我将让下面的所有内容保持原样。答案还是有用的。
这个问题是指当前的 OAuth2 草案 v30和GitHub 的实现。
GitHub 的“Web 应用程序流程”或多或少是规范中描述的授权代码授予的实现。客户端(Web 应用程序)将用户引导至 GitHub 上的一个特殊页面,该页面询问用户是否希望允许应用程序访问他或她的资源。如果这得到确认,用户将被重定向回客户端,然后使用临时代码检索 OAuth 令牌以供将来使用。
如果客户端scope
为用户对 GitHub 的请求提供了参数,则重定向也包含该参数。如果范围是一些只有客户端知道的秘密,客户端可以确定没有其他人创建了该请求,即,用户没有成为 CSRF 攻击的受害者。
但这真的有必要吗?
如果我们选择不使用scope
参数并且用户确实是 CSRF 攻击的受害者,他或她仍然必须接受 GitHub 提出的是否允许客户端访问用户信息的问题。这一步不能跳过。确实,规范说
[The] 授权服务器对资源所有者进行身份验证并获得授权决定(通过询问资源所有者或通过其他方式建立批准)。
如果攻击者使用点击劫持等其他技术来诱骗用户接受请求,我认为无论如何,所有的赌注都没有,而且范围也不会保护用户。
结论:示波器实际上保护用户免受什么威胁?