さてさて、このお話は、どこにあるのかわからない、「ツイット国」のお話です。
実は、この国の人々は、かけ算は得意ですが割り算は苦手……というより、存在すら知りません。
ちょっと変な仮定ですが、物語風 OAuth の説明に必要な仮定ですので。
【はじまりはじまり】
この国に、ツイット太郎という若者がいました。
太郎は、近所のツイット亭というレストランが大のお気に入り。三度の食事をもれなくここで食べていました。
そうなると、面倒なのがお金の支払いです。
そうは言っても、太郎も悪人ではなく、単にお金を持ち歩くのが面倒なだけでした。
そこで、太郎は考えます。
そうだ、ツイット亭の人に、ツイット銀行まで行って、自分の口座から代金を引き落としてもらえば良いんだ。
そうして、太郎は、ツイット亭の人に定期的に銀行まで行くようにお願いし、ツイット亭の人も快く引き受けてくれました。
【Basic 認証の時代】
この時代では、太郎は、お店の人に２つのことを教えます。
１）口座番号（ここでは、12345678 とします）
２）暗証番号（ここでは、7777 とします）
以上です。
お店の人が銀行に行ってお金を引き出すようです。
亭：もしもし、口座番号 12345678 からお金を引き出したいのですが。
銀：では、暗証番号をどうぞ
亭：7777 です。
銀：暗証番号はあっています。では、必要なお金をどうぞ……
こういう会話が交わされます。
……危ないですね？
危ないと言っても、お店の人が太郎の食べてないもののお金まで引き落としてしまうかもしれない……というお話は、今回は、扱いません。
そもそも、そんなおかしなことをするかもしれないお店に、引き落としの代行は依頼しないだろうというのが、基本方針です。
もうひとつの危険性。
もしも、この会話を悪人が聞いたらどうなるでしょう。
早速、ここで聞き耳を立てていた悪人がいたようです。
悪：もしもし、口座番号 12345678 からお金を引き出したいのですが。
銀：では、暗証番号をどうぞ
悪：7777 です。
銀：暗証番号はあっています。では、必要なお金をどうぞ……
悪：しめしめ……。
ただ単に聞いていたことを繰り返すだけですから、簡単なことです。さらに悪いことには、銀行には、「だれがお金を下ろしたか」という記録は一切残りません。
銀行としては、正しい口座番号と暗証番号を知っていたのだから、正しいお客様だと判断するしかないのです。
【OAuth の時代】
さて、Basic 認証はあまりに危険だ……特に、お金を引き出すときの会話を盗み聞きされたどうしようもない。
そこで、時代は、OAuth の時代になりました。
ここでは、ツイット太郎は、ツイット亭と、さらに、ツイット銀行を交えて、４つの情報を決定します。
１）お店の「店舗番号」（ここでは、00110022 とします）
２）お店の「暗証番号」（ここでは、8888 とします）
※ここまでの情報は、「アプリケーションの登録」をしたときに決まります。ユーザーには直接関係ありません。（Twitter が割り当てます）
３）太郎さんの「ツイット亭専用」口座番号（ここでは、11223344 とします）
４）太郎さんの「ツイット亭専用」暗証番号（ここでは、1111とします）
※最後の２つは、「OAuth を承認」したときに決定されます。（Twitter が割り当てます）
さて、今回もお店の人が銀行に向かいお金を下ろします。
亭：店舗番号 00110022 のものですが、11223344 の口座からお金を下ろしたいのですが。
銀：では、最初に、「一回だけ番号」を適当に言ってください。
亭：じゃ、6543 にします。
銀：わかりました。では、「しぐねちゃ」をおしえてください。
亭：えっと〜
ここで、ツイット亭の人は、「しぐねちゃ」を計算し始めます。
計算方法は、
1) 店舗の暗証番号（8888）と、お客様の暗証番号（1111）をくっつけて、88881111 という数字にする。
2）それに、「一回だけ番号」の、6543 をかける
3) 結果は、88881111×6543=1728524313
亭：しぐねちゃは、1728524313 です。
銀：正解です。では、必要なお金をどうぞ……。
さてさて、今回も悪人が聞き耳を立ています。
悪：店舗番号 00110022 のものですが、11223344 の口座からお金を下ろしたいのですが。
銀：では、最初に、「一回だけ番号」を適当に言ってください。
悪：じゃ、6543 にします。
銀：その番号はさっき使ったのでだめです。ちゃんと、「一回だけ番号」を言ってください。
悪：困ったなぁ〜 適当に、9876 です。
銀：わかりました。では、しぐねちゃをおしえてください。
悪：しぐねちゃあれ？ 暗証番号がわからないから、計算できないよ。
ということで、聞き耳をたてていても、失敗に終わるという仕掛けです。
【まとめ】
・OAuth では、暗証番号に相当するものを相手に伝えるかわりに、「それを知らなければできない計算の答」を伝える
だから、聞き耳をたてていても、暗証番号に相当するものは奪えない。
・OAuth では、「一回だけ番号」に相当するものがあって、毎回送信する情報が変化する。
だから、聞き耳をたてて、送信されたものを再利用することができない
（実際には、送信する時点の時刻情報も併せて使います）
・OAuth では、ユーザー情報は、「そのお店専用」になっている。
だから、直接誰がお金を引き出したか（誰が、ツイートしたか）がはっきり残ってしまう
こんなことをして、承認していない相手に情報が漏れ、不正に使われることを防止しているわけです。
【注意】
このお話の前提となっているのは、「ツイット国の人々は割り算ができない」ということです。
現実の世界では、88881111×6543=1728524313 という計算の答え（しぐねちゃ）と、一回だけ番号（6543）がわかっているのですから、割り算をすることで、88881111 というお店と太郎さんの暗証番号がわかってしまいます。
実際、ここの計算は、単なるかけ算ではなくもう少しややこしい計算が使われています。
ただし、このお話のように、計算するのは（コンピュータなら）簡単だけれど、答えからもとの数字を割り出すのは非常に困難という、そういう計算が使われています。
この例を含めて、技術的には、正しくない内容が含まれています。
また、「４つの情報を決定します」とだけ書いた、決め方の部分もかなり面倒なやりとりがあります。
まあ、そういう点を全部無視していますが、なぜ、OAuth のほうが Basic 認証より安全なんだ？ というイメージとしては、大きくは間違っていないと考えています。
