我的问题非常简单:
如果您有两个Web应用程序组件:
如果单个重定向到授权端点(并返回),则可以指定和传输以下信息:
从而在不违反RFC的情况下,在一次往返中转移两个授权(一个在请求url中,另一个在片段中)?
对于每个拨款,一个重定向循环看起来比一个更清晰(即使第二个没有因为先前的授权而阻止)
提前致谢!
参考
编辑1: code_and_token似乎是我所追求的东西......服务器使用其凭据请求访问代码的授权代码授权...以及隐式令牌javascript。正如mov matake所提到的,它是在v11之后从RFC中提取出来的,并没有真正说明原因。 Facebook和谷歌似乎支持这一点,这让我怀疑它会回归。
答案 0 :(得分:1)
OAuth 2.0之前有“code_and_token”响应类型(可能是“token_and_code”)。 但它后来已经从规范中删除了。
因此,在当前规范中,如果您需要服务器代码,那么方式将是
虽然只能为客户端获取范围限制令牌。 或者,您可以在服务器端为客户端代码设置代理。
答案 1 :(得分:1)
token_and_code请求类型已从规范中删除,因为它需要在安全性分析和规则方面进行大量工作,并且没有人愿意这样做。它最初由Twitter工程师提出,他不久后离开了工作组。
它不会添加到规范中,但可以通过扩展轻松引入。 Google在列表中支持此流程,但后来表示他们不会实现它,而是使用HTML5功能实现其他功能。
答案 2 :(得分:0)
http://www.ietf.org/mail-archive/web/oauth/current/msg04969.html和http://www.ietf.org/mail-archive/web/oauth/current/msg03655.html
说“code_and_token”类型是好的,但是RFC没有明确表明片段中的令牌(对于Javascript)应该/可能比访问代码获得的令牌具有更少的权限......
感谢Nov Matake指出code_and_token类型是规范的一部分(在某一点上),因为我在旧的规范版本中错过了它(虽然它被广泛实现)。
看起来它会卷土重来,因为它受到 Google 和Facebook的现有实施的很好支持,似乎是支持用户代理令牌和服务器端的核心请求一次往返的访问代码。
问题似乎是在此上下文中定义“范围”的语义,以及定义范围在单个请求中可以不同的程度。有意义的是,用户代理令牌具有有限的权限,即与客户端应用程序的权限不同。
我们将拭目以待......实施一个涉及RFC的背后的缺点。