是不是oauth_signature重新发明了SSL轮？

Question

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

在推特的案例中：

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

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

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

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

请注意，在这种情况下，twitter只是一个例子。 AFAIK，大多数其他oauth实现者使用类似的策略，这里的要点适用于已经强制要求SSL的任何大型OAuth实现者。

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

Answer 1

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