Introducing OAuth 2.0 を中途半端に訳した
Introducing OAuth 2.0 « hueniverse
意味分かんないとこも多い。ただ訳しただけ。
この辺を踏まえてもう少しまともな訳にする予定。
OAuth 2.0 へ向けて
2010年5月15日（土）
二週間前、IETFのOAuthワーキング／グループが OAuth 2.0 プロトコルの初稿を公表しました。
OAuth とは、利用者がサードパーティとパスワードを共有すること無く、保護されたウェブリソースへのアクセス権を譲与するために考案されたセキュリティプロトコルです。
OAuth 1.0 は 2007年12月に公開され、瞬く間にウェブベースのアクセス権譲与手法の業界標準となりました。
その後 2008年6月に、OAuth 1.0 Revision A と呼ばれるマイナーチェンジ版が公表され、1.0 に存在したセキュリティホールが塞がれました。
そして 2010年4月、OAuth 1.0 は RFC 5849 として公開されました。
OAuth 2.0 は全く新しいプロトコルであり、前のバージョンとの後方互換性はありません。
しかし、OAuth 1.0 で構築された構造とアプローチはOAuth 2.0 でもそのまま適用できます。
また、OAuth 1.0 の公式ガイドと同様の説明がOAuth 2.0 についてもほとんど当てはまります。
多くの高級車には”バレットキー”が付いています。
この特別な鍵は駐車場の係に預けるためのもので、通常の鍵とは違い、トランクを開けたりすることは出来ません。
その代わりに、短い距離を運転することが出来ます。
バレットキーに課せられる制約はともかくとして、そのアイデアは非常に賢い。
つまり、特別な鍵でもって、他の誰かにあなたの車への限られたアクセス権を与える一方で、あなた自身は通常の鍵ですべての機能を使うことができる、というものです。ウェブが成長するに従い、多くのサイトが分散サービスやクラウドコンピューティングを利用するようになってきています。
例えば Flickr の画像を現像したり、Googleのアドレス帳からSNSの友人を探すことも出来ます。
サードパーティのアプリケーションが、 API を利用して複数のサービスを展開することもあります。しかし、これらのアプリケーションは他のサイトにあるユーザーのデータへアクセスしなければならない以上、ユーザーIDとパスワードを利用しなければならない、という問題があります。
これは他のサイトにパスワードを教えてしまうという危険性（オンラインバンキングと他のサイトのパスワードが同じ、ということはままあるでしょう）のみならず、そのサイトが無制限に好きなだけアクセスできるようになることも問題です。
IDとパスワードさえあれば、ユーザーのパスワードを変えてしまったり、あるいはアカウントをロックしてしまうことも、なんでも出来てしまうのです。OAuth はサードパーティとパスワードを共有すること無く、保護されたリソースへのアクセス権を与えることを可能にする手法です。
さらに、アクセス可能範囲や有効期限などを設けて、アクセス権を制限することも出来ます。例えば、ウェブユーザー（リソースの持ち主）が印刷サービス（クライアント）を利用して、ユーザーが写真共有サービス（サーバー）に保存しているプライベートな写真を印刷するとします。
このとき、ユーザーはクライアントである印刷サービスにユーザー名やパスワードを教える必要はありません。
代わりに、サーバーである写真共有サービスと直接認証をし、印刷サービスに限られたアクセス権を与えることに同意すれば良いのです。
新しい版は、プロトコルの最終目標と必要条件を、Yahoo!、 Facebook、Salesforce、Microsoft、Twitter、Deutche Telekom、Intuit、Mozilla、Google などといった幅広い企業との数年に及ぶ議論の末に作られました。
素早く採用されるオープンテクノロジーとして OAuth は、長らく象徴的な存在でした。
2.0 になってもそれは変わりません。
Facebook や Twitter は初稿が公式に発表される以前から OAuth 2.0 のサポートをアナウンスしていました。
新バージョンはなぜ必要か
OAuth 1.0 は、FlickrのAPI認証と、GoogleのAuthSubという二つの既存プロプライエタリプロトコルを、大部分のベースにしています。
結果として、実装という観点では最適解でした。
OAuth 1.0 に3年間取り組む過程で、プロトコルについて再度考え直し、制限があったり、混乱を生んでいた3つの主要な部分について改善しようという機運が高まりました。
認証と署名
OAuth 1.0 の実装に失敗したケースの大部分は、仕様で求められる複雑な暗号化手法によるものでした。
大元の仕様の記述が不十分であったことも原因ですが、RFC5849として公開された新しい版になっても、やはり OAuth 1.0 をクライアント側で使うのは簡単なことではありませんでした。
OAuth は、単純にパスワードを使うことの利便性と簡単さには全くかないませんでした。
例えば、開発者はユーザー名とパスワードを使えばすぐにTwitter と連携する便利なスクリプトを書くことが出来ました。
ところが OAuth を使うとなると、以前は cURL スクリプトで一行で出来ていたことをするために、ライブラリを探し、インストールし、設定しなければなりません。
ユーザー体験と代替トークン発行オプション
OAuth は、ユーザーにアクセス権を譲与するか尋ねることでトークンを取得する部分と、そのトークンを使って保護されたリソースへアクセスする部分という、二つの主要な部分が有ります。
アクセストークンを得るための手法はフローと呼ばれます。
OAuth 1.0 は、ウェブベースアプリケーションによるフロー、デスクトップクライアントによるフロー、携帯可能な、あるいは限られたデバイスによるフローという、
3つのフローから始まりました。
しかし、仕様が洗練されるに従い、これら3つのフローはすべてのクライアントに対して適用可能なように（紙上で）マージされました。
実際には、ウェブベースのアプリケーションについては機能したものの、その他については上手く機能しませんでした。
より多くのサイトが OAuth を使い始め、特に Twitter が OAuth を採用したことにより、OAuth が提供する単一フローは非常に限られており、しばしば貧弱なユーザー体験を提供していたことに気づきました。
一方 Facebook Connect は、ウェブアプリケーションや携帯デバイス、ゲームコンソールといったクライアントのタイプに応じた、よりリッチなフローを提供していました。
スケールにおけるパフォーマンス
大きなプロバイダが OAuth を採用するに従い、このプロトコルはスケールしづらいことが分かってきました。
OAuth 1.0 では、異なる段階での状態管理や、二度と使われずほとんど捨てられる一時認証情報を扱うことを求められます。
さらに、扱いが難しく安全でない（さらにデータセンターと同期をとるのも難しい）、長期にわたって有効な認証情報を発行することも求められる。
加えて、OAuth 1.0 では保護されたリソースのエンドポイントでリクエストの妥当性を検証するために、クライアントの認証情報にアクセス可能にすることを求められます。
この仕組みは、中央の認証サーバにより認証情報が発行され、APIの呼び出しには異なるサーバーを用いるという、ほとんどの大規模プロバイダが持つ典型的な仕組みと真っ向から対立します。
OAuth 1.0 はクライアントの認証情報とトークンの認証情報を両方使うことを要求するため、認証サーバとAPIサーバとの分離を難しくしています。
何が変わったのか
OAuth 2.0 で利用出来る新しい機能の一部を紹介します。
新しい 6 つのフロー
- User-Agent フロー
- user-agent内で動作するクライアント用です（主にウェブブラウザ）。
- ウェブサーバフロー
- HTTP 経由でアクセスできるウェブサーバアプリケーションの一部として動作するクライアント用です。これは OAuth 1.0 で提供されていたフローの簡易版です。
- デバイスフロー
- ユーザー名とパスワードフロー
- クライアントが認証情報を適切に扱うことをユーザが信頼してはいるものの、ユーザー名とパスワードをクライアントに保存されることを望まない場合のフローです。このフローはユーザーとクライアント間に相当の信頼関係がある場合にのみ有効です。
- クライアントクレデンシャルズフロー
- クライアントが認証情報を用いてアクセストークンを得る際のフローです。このフローは、いわゆる 2-legged と呼ばれるケースに該当します。
- アサーションフロー
ネイティブアプリケーション（デスクトップパソコンや携帯デバイス上で動作するアプリケーション）の場合は、上記のフローを複数用いることによって OAuth 2.0 の利用が可能です。
無記名式トークン
OAuth 2.0 では、既存のクッキー認証に基づいた、暗号化不要の認証方式を利用できます。この方式では、本来 HMAC とトークンシークレットによって署名されたリクエストを送信する所を、トークン自信を秘密情報として、 HTTPS で送信します。
この方式を用いれば、めんどうなリクエストや署名などの過程を経ずに、cURL やその他のシンプルなスクリプトで API コールを実装できます。
単純化された署名
署名の方式は非常に単純化されました。
OAuth の署名だけに特化したパースやエンコード、パラメータの並べ替えは不要になります。
署名のための秘密情報も、これまで二つ必要だったものが一つに減ります。
