Oauth 1.0 について。

なんで調べたのか

Twitter の APIいじってた時に訳が分からなくなったので。

Oauth 1.0

参照先：https://tools.ietf.org/html/rfc5849#section-3

概要

OAuth は クライアント(1) にリソースオーナー(2) の代理でサーバー(3) のリソースにアクセス権限を与える方法を提供している。また、ユーザー代理リダイレクションを使って、リソースオーナが証明書(4)を自分のリソースに第三者がアクセスできるプロセスも提供している。

例えば、webサービスを使っているユーザー（リソースオーナー）が印刷サービス（クライアント）に、写真共有サービス（サーバー）に保管されているそのユーザーのプライベートの写真へのアクセスを、印刷サービスにユーザー名やパスワードを教えることなく、認めることができる。証明書を教えない代わりに、ユーザーは印刷サービスが特定の代理証明書を発行することを承認する。

(1) Webサービスの管理人のこと
(2) エンドユーザー、つまりそのサービス利用者のこと
(3) twitter 等のこと
(4) ユーザ名やパスワード等

OAuth が生まれた経緯

以前のクライアント・サーバー間のモデルではクライアントは自分の証明書を使ってサーバーに保管されているクライアント自身のリソースにアクセスしていた。
しかし、分散型Web やクラウド計算機の使用する機会が増えるにつれて、第三者のアプリケーションはそれらに保管されているリソースにアクセスする必要が出てきた。

OAuth は上記のモデルに第三の役割、リソースオーナーを導入した。OAuth モデルではクライアント（リソースオーナーではなく、その代理の存在）はリソースオーナーによって管理されているがサーバーに保管されているリソースへのアクセスを要求する。それに加えて、OAuth によってサーバーはリソースオーナーの権限だけでなくリクエストを送ってきているクライアントの身元を確認する。

クライアントがリソースにアクセスするために、まずリソースオーナーから許可を得なければならない。この許可はトークンと共有された一致する秘密なもの二つの形式で表される。トークンの目的はリソースオーナーがクライアントに証明書を共有する必要をなくさせるためである。リソースオーナーの証明書と違ってトークンは限られた領域と有効時間内で発行され、無効になるときは独立してそれが行われる。

クライアントに特定の代理証明書を発行するには、二つの方法がある。一つが、エンドユーザーがサーバーに直接権限メソッドの使用をクライアントに認めるトークンを発行することを承認することで、エンドユーザー自身のリソースにクライアントがアクセスすることを承認する方法である。二つ目が、二つの証明書のセットを使う、承認されたHTTPリクエストを作る方法である。その二つの証明書セットのうちのもう1つは、その要求を代行するリソース所有者を識別する。

流れ