Twitter API を使用しているときに、oauth_signature基本的に (リクエスト本文 + リクエスト パラメータ + nonces/timestamps + a consumer_secret) のハッシュである に出会いました。はconsumer_secret、要求を送信しているアプリケーションだけが知っています。
ツイッターの場合：
- すべての通信は SSL 経由で行う必要があります。
- twitter は、
consumer_secret承認された各アプリケーションに を発行します。
の主な用途はoauth_signatureMITM を防止すること (つまり、おっぱい (輸送中の改ざん) を防止すること) であるため、この特定のユース ケースは相互 SSL を介して解決できるように思えます。
- Twitter は を発行する代わりに、
consumer_secretアプリケーションごとに SSL 証明書を発行できます。
このクライアント ssl-certificates のアイデアは 1990 年代のインターネットの奥義のように思えるかもしれませんが、クライアント証明書の信頼チェーンを検証する際の問題が主な原因で、成功しませんでした。Twitter が証明書の唯一の発行者であり検証者であるため、ここではその問題は発生しません。欠点は、最初のアプリケーション/クライアント ssl 証明書を作成するために Twitter に代わってはるかに複雑な作業が必要になることですが、REST API の単純さには見返りがあり、クライアントが本人であるという保証に依存できます。
この場合、twitter は単なる例であることに注意してください。知る限り、他のほとんどの oauth 実装者は同様の戦略を使用しており、ここでのポイントは、すでに SSL を義務付けている大規模な OAuth 実装者に適用されます。
ここで何が欠けていますか？インターネット慣性？