某日、某所で行ったプレゼン資料を公開

1. OAuth について @tzmtk

2. アジェンダ OAuth とは？ 認証と認可 登場人物 OAuth をやる意味 OpenID と OAuth OAuth 最近のトピック OAuth とセキュリティ おまけ

3. OAuth とは？ OAuth とは？ ある Web サービス上に存在するユーザー固有のデータを、外部サービスに対して安全に提供するためのオープンな認可のプロトコル いつ／どこで／だれが？ 2007 年 12 月４日に米国のコミュニティ "OAuth.net" によって策定された（ OAuth Core 1.0 ） OAuth.net （ oauth.net/code ）上に仕様がすべて公開されている、オープンな技術 Author: Blaine Cook(ex-Twitter), Chris Messina, Ben Laurie(Google), Kellan Elliott-McCrea(Flickr), Eran Hammer-Lahav(Yahoo!), David Recordon(ex-sixapart)

4. OAuth とは？ なぜ？ Twitter にいた Braine Cook が、 API 公開の際に "OpenID" を使おうと考えていたが、 API のアクセス権限委譲のしくみがなく、新しく " 認可 " のための標準技術が必要だと考え、 Flickr や Google のエンジニアと相談して "OAuth" の原型を考えたという説が有力 Flickr API や Google の AuthSub 、 Yahoo! の BBAuth を参考に有識者間で協議し、仕様が策定された 主な OAuth 提供サービス グローバル : Google, 米 Yahoo!, Twitter, MySpace, brightkite 国内 : Yahoo! JAPAN, smart.fm( 旧 iKnow!) OpenSocial の基盤技術としても使われている（くわしくは @ritou へ）

5. 認証と認可 認証（ Authentication ）と認可（ Authorization ） 認証（ Authentication ） そのユーザーが ID 、パスワード等によって本人であると主張する行為を確認する処理のこと 認可（ Authorization ） 本人であると確認されたユーザーに対して、適切なサービスリソース、およびアクセス権限を付与する処理のこと 認可を行うためには、その前段階の本人確認が必須になるため、認証は認可の前提条件になっているといえる

6. 登場人物 OAuth の登場人物 "Service Provider" ユーザーリソースを提供する Web サービス "Consumer" Service Provider の持つユーザーリソースへアクセスする Web サイト、またはクライアントアプリケーション "User" Service Provider 上にアカウントを持っているエンドユーザー、データの持ち主 ユーザーのデータを保有する Service Provider 、データへのアクセス権限を委譲される Consumer 、アクセス権限の委譲を同意する User 、の三者間でやりとりが行われる

7. Service Provider （フォトストレージサービス） User （写真データの持ち主） Consumer （フォトプリントサービス） 1. 認可取得指示 2. Request Token 取得 3. User を Service Provider へリダイレクト 4. Consumer への認可を同意 5. User を Consumer へリダイレクト 6. Request Token と Access Token を交換 7. Access Token を使ってリソースへアクセス

8. OAuth をやる意味（ Service Provider ） 外部サービス連携のための基盤づくり ユーザー固有のデータを扱う API を外部公開するには、前提条件としてまず OAuth が必要になる API 公開によるサービスへのメリット享受、直接マネタイズできる API の提供など API 経由での自サービス利用機会向上、データ量の増加、精度向上 OpenID と異なり、モバイルやクライアントアプリ、その他のデバイスへの展開が可能

9. OAuth をやる意味（ Service Provider ） SP の ID 価値向上（※議論あり） OAuth は ID 連携のしくみとしても利用できるため、外部サイト =Consumer へ SP の ID でログインするためのソリューションとしても利用できる 外部サイトへログインするためにも使われるようになれば、 ID の利用頻度が上がりユーザーにとっても SP の ID の価値があがる 例 : Twitter OAuth->Friendfeed など、シンプルに認証（ + 認可）できる ログイン率向上 外部サービスをきっかけとしてログイン頻度が上がり、結果的に自サービス上でのログイン率が向上

10. OAuth をやるメリット（ Consumer ） 仕様がオープンなため情報が豊富 ライブラリが多数用意されている 各サービスが OAuth という共通の仕様を利用することにより、従来のように各社の仕様に合わせた個別の開発が不要になり、サービス開発の負担が軽減される Consumer 側で ID 、パスワードなどのセンシティブな情報を持たなくて良くなる

11. OpenID と OAuth OpenID シングルサインオン（ =ID 連携）、属性交換のためのオープンな分散型認証技術 米国 OpenID Foundation によって策定された 特定の Identity Provider の ID に依存しない " 分散型 " がキーワード 元々はブログのコメント受付時に認証するための、ライトな認証を目的につくられた ID 連携には利用しやすいが、 " 認可 " に踏み込んでないので API のアクセス権限委譲まではできない 事前登録が一切不要

12. OpenID と OAuth OAuth そもそも " 認可 " を目的に作られたオープンなプロトコル OAuth.net （ OpenID Foudation ほど組織化されてない）によって策定 " 認証 " は " 認可 " の前提条件なのであって本来の目的ではない Service Provider から Consumer を識別するために必ず事前登録（＝ Consumer Key 発行）が必要

13. OpenID と OAuth 違いをまとめると？ OpenID= シングルサインオン（＝ ID 連携）、属性交換のための比較的ライトでオープンなプロトコル。 " 認可 " までてきない OAuth ＝ " 認可 " を目的とした、オープンなプロトコル。 " 認可 " に " 認証 " が前提になっているため、シングルサインオンにも使えてしまう

14. OpenID と OAuth 個人的に思うところ " 属性交換 " については、 OpenID AX でやるべきか、 OAuth の属性交換 API でやるべきか正直微妙 API を使ってもらってなんぼ、の SP であれば OAuth を積極的に推進すべき ID 連携、属性交換のみでいいのであれば、 OpenID で好きにやってもらう？ OpenID の拡張仕様で OAuth Extension があるので、将来的には既存の OpenID 対応サイトも OAuth を利用しやすくなる OpenID CX など、契約ベースの属性交換を行うための拡張仕様が検討されており、今後 OpenID ＋決済が広まる可能性あり

15. OAuth 最近のトピック セキュリティの脆弱性が発覚 セッション固定攻撃（ OAuth Session Fixation Attack ）への脆弱性（ Session Fixation Security Advisory ？） 2009 年 4 月 23 日、メールやメッセで URL 送信するなどの Social Engineering の手法でユーザー本人に同意さえ踏ませれば、 API へのアクセス権限を不正利用者が乗っ取れてしまう脆弱性が発覚 2009 年 6 月 24 日に、上記の問題を解決した "OAuth Core 1.0 Revision A" の仕様が策定され、解決済み 米 Yahoo! 、 Yahoo! JAPAN の OAuth は Revision A に対応した仕様で公開

16. OAuth 最近のトピック MobsterWorld の大量スパム DM 送信について 2009 年 8 月 1 日頃から、 Twitter ユーザー間でソーシャルゲームアプリ "MobsterWorld" に関する特定の DM が意図せず多数送信されているという騒動が発生 OAuth で同意した瞬間に、 MobsterWorld の Twitter アカウントを自動でフォローするとともに、そのユーザーの全 followers に同様の DM を一括送信してしまうというしくみ DM 内に含まれる URL をクリックし、 MobsterWorld のサイトにアクセスした後にさらに進むと Twitter OAuth の同意画面が表示されるので、そこで "Allow" （同意）さえ押さなければ問題は発生しない OAuth の同意画面上だけの説明では何が起こるか分からない、ユーザー自身も同意画面を慎重に読まない、といった点から生じた問題といえる（日本人ユーザーにとっては英語の説明だったことも少なからず影響）

17. セキュリティと OAuth 外部サイト上での ID 、パスワード入力 従来、 Web メールサービスのアドレス帳機能を外部サイトが利用する際に、ユーザー自身に直接 ID 、パスワードを入力させ、外部サイトのサーバがユーザーに成り代わってアクセス（スクレイピング）する行為が横行していた（ Twitter では今も横行している） 本来、 ID とパスワードは外部サービスに渡しては絶対にいけないもの。決済ができるサービスや、センシティブな個人情報を扱うサービスでは特にそう それをさせてしまっているサービスは、悪用しようと思えばいくらでも悪用できてしまうため、実質フィッシングに近い行為を行っていると思った方がいい OAuth は、そういったセキュリティ上の問題を解決できるすばらしいソリューション

18. 妄想 OAuth の SP 、 OAuth 対応 API が増えてほしい とにかく OAuth 対応 API がまだまだ少ないので、世にある Web サービスはどんどん OAuth やってほしい OAuth の SP が増えれば増えるほど、マッシュアップサービスや○○アプリの可能性が広がる OAuth は Social と相性がいい ヒト単位のデータを受け渡すための OAuth と、ヒトをベースにしたソーシャル系サービスは相性がいい、と勝手に思っている。ソーシャル系のサービスこそガンガン API 出してほしい API 公開は後発サービスにこそ有効な戦略 強い No.1 がいる場合、それに追いつくために後発サービスは外部リソースでもなんでも利用して自サービスの価値向上を図る策が有効 とにかく外部に面を増やす、サービスのデータを太らせる、自分で作れない機能を外部の開発者に作ってもらうなど Twitter OAuth Twitter はいま最も使われている Service Provider （ 2009 年 8 月時点） Twitter OAuth により、 Twitter はいつのまにかに巨大 Identity Provider になっていた気がしてる

19. おまけ 「 OAuth Core 1.0 Revision A 」を日本語訳してみた http://d.hatena.ne.jp/tzmtk/20090723/p1