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

Question

在使用twitter API时,我遇到的oauth_signature基本上是(请求体+请求参数+ nonces/timestamps + a consumer_secret)的哈希值.该consumer_secret已知仅到正在发送的请求的应用程序.

在Twitter的案例中:

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

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

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

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

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

我在这里错过了什么？互联网惯性？

Answer 1

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