5

在使用 twitter API 时，我遇到了oauth_signature基本上是（请求正文 + 请求参数 + nonces/timestamps + a consumer_secret）的哈希。consumer_secret只有发送请求的应用程序才知道。

在推特的例子中：

  • 所有通信都必须通过 SSL 进行。
  • twitterconsumer_secret向每个授权的应用程序发出 。

由于 的主要用途oauth_signature是防止 MITM（即没有山雀（在运输中篡改）:)，在我看来，这个特定的用例可以通过 Mutual SSL 解决

  • Twitterconsumer_secret可以为每个应用程序颁发 SSL 证书，而不是颁发 .

虽然这种客户端 ssl 证书的想法可能看起来像 1990 年代的互联网奥秘，但它并不成功，主要是因为在验证客户端证书的信任链时遇到了麻烦。这个问题在这里不会出现，因为 twitter 将是证书的唯一颁发者和验证者。缺点是代表 Twitter 需要付出更多努力来生成初始应用程序/客户端 ssl 证书，但回报将在于 REST API 的简单性，这可以依赖于客户是他所说的那个人的保证。

请注意，twitter 只是本例中的一个示例。AFAIK，大多数其他 oauth 实现者使用类似的策略，这里的要点适用于任何已经强制使用 SSL 的大规模 OAuth 实现者。

我在这里想念什么？互联网惯性？

4

1 回答 1

-1

相互 SSL 证书虽然是个好主意，但并不能完全解决 OAuth 试图解决的问题。OAuth 有两组令牌。一种用于应用程序（可以由 SSL 证书替换），也用于特定用户。当您尝试确定是否允许此授权应用程序访问此特定用户时，SSL 证书无济于事。

于 2012-09-07T15:21:21.200 回答