【发布时间】:2011-01-23 13:37:47
【问题描述】:
服务器不能只是将临时凭证“升级”为令牌凭证并保留相同的密钥和秘密吗?
客户端可以在收到来自服务器的回调后立即开始进行经过身份验证的调用,说明临时凭据已“升级”。
如果临时凭据尚未升级(即客户端不等待回调),则经过身份验证的调用失败。
所以问题是为什么在回调后额外调用服务器以“交换”令牌凭据的临时凭据?
【问题讨论】:
服务器不能只是将临时凭证“升级”为令牌凭证并保留相同的密钥和秘密吗?
客户端可以在收到来自服务器的回调后立即开始进行经过身份验证的调用,说明临时凭据已“升级”。
如果临时凭据尚未升级(即客户端不等待回调),则经过身份验证的调用失败。
所以问题是为什么在回调后额外调用服务器以“交换”令牌凭据的临时凭据?
【问题讨论】:
您可以以这种方式实现 OAuth,但据我了解,将请求令牌与访问令牌分开确实提供了额外的安全层。
OAuth 包括两种 Token: 请求令牌和访问令牌。每个 Token 在 OAuth 委托工作流程。尽管 主要是 OAuth 如何 规范演变,两个Token 设计提供了一些可用性和 使它成为的安全功能 值得留在 规格。 OAuth 在两个 通道:一个前置通道,它是 用于吸引用户并请求 授权和使用的反向通道 由消费者直接交互 与服务提供商。通过限制 反向通道的访问令牌, 令牌本身仍然隐藏 来自用户。这允许访问 具有特殊含义的代币 尺寸比 前通道请求令牌是 请求时向用户公开 授权,在某些情况下需要 手动输入(移动设备 或机顶盒)。
因此,据我了解,通过将访问令牌限制为直接在消费者(您的服务)和提供者(您正在访问的服务)之间的通道,您可以获得安全的访问令牌(即,攻击者没有),即使用户的机器或用户与您的服务的网络连接受到威胁。如果只是简单地升级了请求令牌,那么任何嗅探用户网络连接的人都可以轻松获得请求/访问令牌,我们希望对其保密,因为它可以使用(当然,与您的消费者令牌一起使用),可能用于很长一段时间,访问用户的数据。服务器到服务器的连接通常更安全。
此外,正如上面所指出的,在请求令牌实际上必须由用户输入的情况下(因此可能很短),这可以让您拥有更长的密钥。
【讨论】: