ここですという名前のブログやさん

さて、OAuth の具体的な対応方法は一時お休みして、そもそも、OAuth 認証というのが、Basic 認証に比べてなぜ安全なのか、とう安全なのかを書いてみようと思います。
一般的な解説記事などによれば、OAuth が安全なのは、「ユーザーのIDとパスワードを使わないから」といわれています。
確かにこの通りではあるのですが、OAuth では、その代わりに、Consumer key, Consumer secret, Access Token, Access Token Secret という４つの鍵を使用します。
そして、確かに、（ボットがそうするように）このキーを使って、ユーザーのかわりに様々な操作をすることができます。
さて、IDとパスワードなら危険で、同じように様々な操作をすることができる、４つの鍵なら安全だというのはどういうことでしょうか？

まず、何をもって「安全」とするかを考えなければなりません。
たとえば、従来の Basic 認証ならユーザーに成り代わっていろいろなことができるけど、OAuth 認証ではできることが限られるというわけではありません（ただし、実際には、「できることを制限する」という機能はあります）
また、一時話題になった、ダイレクトメッセージの機能を使って、SPMA のような拡散をさせるというものがありましたが、これも、OAuth 認証の元で動いていました。
ですから、ユーザーが、「承認した」状態では、機能的にはどちらであっても同じことできてしまいます。

では、何が「安全」なのでしょうか？　それは

・ユーザーがいつでも（自分のパスワードを変更しなくても）承認を取り消すことができる。
・ユーザーがいつでも自分の都合でパスワードを変更できる。
・OAuth 認証では、ホストに送信される情報が盗まれても、それが流用できない（Basic 認証だとこれができてしまいます）

という点になります。

【ユーザーはいつでも承認を取り消すことができる】

従来のBasic認証では、それが、Twitter クライアントであっても、つぶやきの転送のようなものであっても、IDとパスワードを、連絡しなければなりません。（または、設定しなければなりません）
逆に言えば、何かのサービスを「もう使いたくない」として、絶対に使われないようにしようと思えば、パスワードを変更するという方法しかありませんでした。
新しいパスワードを知らない、クライアントなりサービスなりは、それ以降ユーザーのアカウントにアクセスできなくなります。
しかし、言い換えれば、そのほかの「まだ使いたい」サービスなどに対しても、パスワードを変更したと連絡する必要があるということです。

これに対して、OAuth 認証の枠組みでは、特定のサービスの「承認を取り消す」ことで、それ以降アクセスを禁止することができます。

【ユーザーはいつでも自分のパスワードを変更できる】

これは、前項とは逆の状況です。
たとえば、安全のために定期的にパスワードを変更する。または、パスワードが漏れたらしいので、変更する。
これも、従来の Basic 認証の枠組みでは、自分が使っているクライアントやサービスの事情をいちいち気にしなければなりません。

これに対して、OAuth 認証の枠組みでは、ユーザー以外のサービスはパスワードを使いませんから、いつでもパスワードを変更することができます。

【ホストに送信される情報が流用できない】

実は、「安全」という観点ではこれが一番重要なポイントです。
まず、インターネットでは、「暗号化」がなされていない限り、ホストに送信される情報は（受ける情報も）盗まれる可能性があるというのが前提となります。
ですから、Basic 認証であろうと、OAuth 認証であろうと、ホストに送信される「ユーザーのアカウントにアクセスするための情報」は、盗まれる可能性があります。

ただ、「盗まれた」情報が流用できるかどうかで、Basic 認証と、OAuth 認証の安全性に差が出ているわけです。

Basic 認証では、ホストに送信されるユーザー情報は、ユーザーのIDとパスワードから生成されるもので、いつでも同じものです。
つまり、一度盗まれてしまえば、何度でも（ユーザーが気づいてパスワードを変更するまで）利用できてしまいます。
これが、Basic 認証におけるセキュリティ上の問題点とされていたわけです。

一方で、OAuth 認証において、ホストに送信されるユーザー情報は、「アクセスの度に変化」します。
このため、ユーザー情報が盗まれたとしても、その情報は、２度と使えないという仕掛けになっています。

その仕掛けについて、少々書いてみましょう。

OAuth では、ホストに送信されるユーザー情報は、
「Consumer key」「Access Token」「付加情報」「署名」
です。
ここで注意したいのは、先に紹介した４つの鍵のうち、２つの鍵しか送信しないということです。
つまり、送信する情報が丸ごと盗まれたとしても、まだ、２つの鍵については秘密が守られるということです。

また、「付加情報」には、「Timestamp = 送信時刻」と「nonce = ランダムな文字列」が含まれます。
送信時刻が含まれるため、このTimestamp とかけ離れた（実際には、５分を超えたずれのある）時刻に受け取られたものは、ホストから拒否されます。
まず、盗んだ情報を元に、毎日アクセスするなどということはできないわけです。
さらに、「ランダムな文字列」というのは、単に、ランダムなだけではなく、「送信の度に異なる」ものでなければなりません。

送信時刻は、５分までのずれが許されました。といって、盗んだ情報をすぐに使おうとしても、今度は、「nonce = ランダムな文字列」として、「同じものが送信された」ということで、やはり、ホスト側から拒否されます。

したがって、もしも、この情報を盗んだとしても、２度とつかない情報だというわけです。

最後に、「署名」です。
この署名は、送信する、「Consumer key」「Access Token」「付加情報」の部分を、「鍵」を使って行います。
処理の内容は省略しますが、つまりは、署名に使う「鍵」を知っている人でないと署名を作成できないというものです。

さて、この、「鍵」になるのが、残った、Consumer secret, Access Token Secret の２つです。
つまり、この鍵を知らなければ、署名が作成できません。

前述の通り、「全く同じユーザー情報は２度と使えない」「異なる情報を作ろうとすれば、secret という名前のついた鍵が必要」「しかも、secret という名前のついた鍵は、ホストに送信されることがない」ということで、情報が盗まれたとしても安全だという仕掛けです。

【最後に――全部の鍵が盗まれたら】

以上のことを踏まえると、Consumer key, Consumer secret, Access Token, Access Token Secret が揃っていれば、不正アクセスでもできてしまうということになります。
一応、Consumer secret, Access Token Secret は盗まれることがない仕掛けになっているのですが、パソコンを丸ごと盗まれるとか、いろいろあるかもしれません。

実は、その場合でも、気づけば（というか、本当は、盗まれたことに気づくということが最も重要）アプリケーションの作者は、Consumer key, Consumer secret を変更できます。この時点で、盗まれた、Consumer key, Consumer secret は、無効になってしまいます。
しかも、Access Token, Access Token Secret も、「このアプリケーション専用」なので、他のアプリケーションから、盗んできた Access Token, Access Token Secret をもとに不正アクセスするということもできません。

このようなわけで、少なくとも、被害拡大は防げるようになっているわけです。