oauth_signature 不是在重新发明 SSL 轮子吗？

Question

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

就 Twitter 而言：

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

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

• Twitter 可以为每个应用程序颁发 SSL 证书，而不是颁发 consumer_secret。

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

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

我在这里缺少什么？互联网惯性？

Answer 1

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