因此,如果用户使用用户名/密码对站点进行身份验证,他们会获得一个会话令牌,该令牌会被传回服务器以验证他们是谁。
但是,当您使用 twitter 或 4square 之类的 API 时,您同时拥有令牌和秘密。向 api 令牌添加 api 秘密有什么额外价值,特别是如果您要在 URL 中同时发送它们。
我能想到的唯一合理的事情是它使数字空间真的很大,但是 128 位令牌已经有一个巨大的数字空间,所以这让人相信这可能不是额外价值的原因。
那么为什么有 2 个值,这两个值都在每个请求中传输?
因此,如果用户使用用户名/密码对站点进行身份验证,他们会获得一个会话令牌,该令牌会被传回服务器以验证他们是谁。
但是,当您使用 twitter 或 4square 之类的 API 时,您同时拥有令牌和秘密。向 api 令牌添加 api 秘密有什么额外价值,特别是如果您要在 URL 中同时发送它们。
我能想到的唯一合理的事情是它使数字空间真的很大,但是 128 位令牌已经有一个巨大的数字空间,所以这让人相信这可能不是额外价值的原因。
那么为什么有 2 个值,这两个值都在每个请求中传输?
这种说法是不正确的:
两者都在每个请求中传输
秘密永远不会发送。相反,每个请求都使用密钥进行签名。从Twitter API 文档中,发送的数据在Authorization标头中是:
OAuth oauth_consumer_key="xvz1evFS4wEEPTGEFPHBog",
oauth_nonce="kYjzVBB8Y0ZFabxSWbWovY3uYSQ2pTgmZeNu2VS4cg",
oauth_signature="tnnArxj06cWHq44gCs1OSKk%2FjLY%3D",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="1318622958",
oauth_token="370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb",
oauth_version="1.0"
文档继续说:
oauth_signature 参数包含一个通过签名算法运行所有其他请求参数和两个秘密值生成的值。签名的目的是让 Twitter 可以验证请求在传输过程中没有被修改,验证发送请求的应用程序,以及验证应用程序是否有权与用户的帐户进行交互。
正如文档所述,签名用于身份验证并确保请求在签名后不被篡改。
这种身份验证策略的另一个优点是它可以很好地与无状态服务交互。