O Auth

4,006 views

Published on

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

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,006
On SlideShare
0
From Embeds
0
Number of Embeds
21
Actions
Shares
0
Downloads
27
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

O Auth

  1. 1. OAuth について @tzmtk
  2. 2. アジェンダ <ul><ul><li>OAuth とは? </li></ul></ul><ul><ul><li>認証と認可  </li></ul></ul><ul><ul><li>登場人物 </li></ul></ul><ul><ul><li>OAuth をやる意味 </li></ul></ul><ul><ul><li>OpenID と OAuth </li></ul></ul><ul><ul><li>OAuth 最近のトピック </li></ul></ul><ul><ul><li>OAuth とセキュリティ </li></ul></ul><ul><ul><li>おまけ </li></ul></ul>
  3. 3. OAuth とは? <ul><ul><li>OAuth とは? </li></ul></ul><ul><ul><ul><li>ある Web サービス上に存在するユーザー固有のデータを、外部サービスに対して安全に提供するためのオープンな認可のプロトコル </li></ul></ul></ul><ul><ul><li>いつ/どこで/だれが? </li></ul></ul><ul><ul><ul><li>2007 年 12 月4日に米国のコミュニティ &quot;OAuth.net&quot; によって策定された( OAuth Core 1.0 ) </li></ul></ul></ul><ul><ul><ul><li>OAuth.net ( oauth.net/code )上に仕様がすべて公開されている、オープンな技術 </li></ul></ul></ul><ul><ul><ul><li>Author: Blaine Cook(ex-Twitter), Chris Messina, Ben Laurie(Google),  Kellan Elliott-McCrea(Flickr), Eran Hammer-Lahav(Yahoo!), David Recordon(ex-sixapart) </li></ul></ul></ul>
  4. 4. OAuth とは? <ul><ul><li>なぜ? </li></ul></ul><ul><ul><ul><li>Twitter にいた Braine Cook が、 API 公開の際に &quot;OpenID&quot; を使おうと考えていたが、 API のアクセス権限委譲のしくみがなく、新しく &quot; 認可 &quot; のための標準技術が必要だと考え、 Flickr や Google のエンジニアと相談して &quot;OAuth&quot; の原型を考えたという説が有力 </li></ul></ul></ul><ul><ul><ul><li>Flickr API や Google の AuthSub 、 Yahoo! の BBAuth を参考に有識者間で協議し、仕様が策定された </li></ul></ul></ul><ul><ul><li>主な OAuth 提供サービス </li></ul></ul><ul><ul><ul><li>グローバル : Google, 米 Yahoo!, Twitter, MySpace, brightkite </li></ul></ul></ul><ul><ul><ul><li>国内 : Yahoo! JAPAN, smart.fm( 旧 iKnow!) </li></ul></ul></ul><ul><ul><ul><li>OpenSocial の基盤技術としても使われている(くわしくは @ritou へ) </li></ul></ul></ul>
  5. 5. 認証と認可 <ul><ul><li>認証( Authentication )と認可( Authorization ) </li></ul></ul><ul><ul><ul><li>認証( Authentication ) </li></ul></ul></ul><ul><ul><ul><ul><li>そのユーザーが ID 、パスワード等によって本人であると主張する行為を確認する処理のこと </li></ul></ul></ul></ul><ul><ul><ul><li>認可( Authorization ) </li></ul></ul></ul><ul><ul><ul><ul><li>本人であると確認されたユーザーに対して、適切なサービスリソース、およびアクセス権限を付与する処理のこと </li></ul></ul></ul></ul><ul><li>  </li></ul><ul><li>認可を行うためには、その前段階の本人確認が必須になるため、認証は認可の前提条件になっているといえる </li></ul>
  6. 6. 登場人物 <ul><ul><li>OAuth の登場人物 </li></ul></ul><ul><ul><ul><li>&quot;Service Provider&quot; </li></ul></ul></ul><ul><ul><ul><ul><li>ユーザーリソースを提供する Web サービス </li></ul></ul></ul></ul><ul><ul><ul><li>&quot;Consumer&quot; </li></ul></ul></ul><ul><ul><ul><ul><li>Service Provider の持つユーザーリソースへアクセスする Web サイト、またはクライアントアプリケーション </li></ul></ul></ul></ul><ul><ul><ul><li>&quot;User&quot; </li></ul></ul></ul><ul><ul><ul><ul><li>Service Provider 上にアカウントを持っているエンドユーザー、データの持ち主 </li></ul></ul></ul></ul><ul><li>  </li></ul><ul><li>ユーザーのデータを保有する Service Provider 、データへのアクセス権限を委譲される Consumer 、アクセス権限の委譲を同意する User 、の三者間でやりとりが行われる </li></ul>
  7. 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. 8. OAuth をやる意味( Service Provider ) <ul><ul><li>外部サービス連携のための基盤づくり </li></ul></ul><ul><ul><ul><li>ユーザー固有のデータを扱う API を外部公開するには、前提条件としてまず OAuth が必要になる </li></ul></ul></ul><ul><ul><ul><li>API 公開によるサービスへのメリット享受、直接マネタイズできる API の提供など </li></ul></ul></ul><ul><ul><ul><li>API 経由での自サービス利用機会向上、データ量の増加、精度向上 </li></ul></ul></ul><ul><ul><ul><li>OpenID と異なり、モバイルやクライアントアプリ、その他のデバイスへの展開が可能 </li></ul></ul></ul>
  9. 9. OAuth をやる意味( Service Provider ) <ul><ul><li>SP の ID 価値向上(※議論あり) </li></ul></ul><ul><ul><ul><li>OAuth は ID 連携のしくみとしても利用できるため、外部サイト =Consumer へ SP の ID でログインするためのソリューションとしても利用できる </li></ul></ul></ul><ul><ul><ul><li>外部サイトへログインするためにも使われるようになれば、 ID の利用頻度が上がりユーザーにとっても SP の ID の価値があがる </li></ul></ul></ul><ul><ul><ul><li>例 : Twitter OAuth->Friendfeed など、シンプルに認証( + 認可)できる </li></ul></ul></ul><ul><ul><li>ログイン率向上 </li></ul></ul><ul><ul><ul><li>外部サービスをきっかけとしてログイン頻度が上がり、結果的に自サービス上でのログイン率が向上 </li></ul></ul></ul>
  10. 10. OAuth をやるメリット( Consumer ) <ul><ul><li>仕様がオープンなため情報が豊富 </li></ul></ul><ul><ul><li>ライブラリが多数用意されている </li></ul></ul><ul><ul><li>各サービスが OAuth という共通の仕様を利用することにより、従来のように各社の仕様に合わせた個別の開発が不要になり、サービス開発の負担が軽減される </li></ul></ul><ul><ul><li>Consumer 側で ID 、パスワードなどのセンシティブな情報を持たなくて良くなる </li></ul></ul>
  11. 11. OpenID と OAuth <ul><ul><li>OpenID </li></ul></ul><ul><ul><ul><li>シングルサインオン( =ID 連携)、属性交換のためのオープンな分散型認証技術 </li></ul></ul></ul><ul><ul><ul><li>米国 OpenID Foundation によって策定された </li></ul></ul></ul><ul><ul><ul><li>特定の Identity Provider の ID に依存しない &quot; 分散型 &quot; がキーワード </li></ul></ul></ul><ul><ul><ul><li>元々はブログのコメント受付時に認証するための、ライトな認証を目的につくられた </li></ul></ul></ul><ul><ul><ul><li>ID 連携には利用しやすいが、 &quot; 認可 &quot; に踏み込んでないので API のアクセス権限委譲まではできない </li></ul></ul></ul><ul><ul><ul><li>事前登録が一切不要 </li></ul></ul></ul>
  12. 12. OpenID と OAuth <ul><ul><li>OAuth </li></ul></ul><ul><ul><ul><li>そもそも &quot; 認可 &quot; を目的に作られたオープンなプロトコル </li></ul></ul></ul><ul><ul><ul><li>OAuth.net ( OpenID Foudation ほど組織化されてない)によって策定 </li></ul></ul></ul><ul><ul><ul><li>&quot; 認証 &quot; は &quot; 認可 &quot; の前提条件なのであって本来の目的ではない </li></ul></ul></ul><ul><ul><ul><li>Service Provider から Consumer を識別するために必ず事前登録(= Consumer Key 発行)が必要 </li></ul></ul></ul>
  13. 13. OpenID と OAuth <ul><ul><li>違いをまとめると? </li></ul></ul><ul><ul><ul><li>OpenID= シングルサインオン(= ID 連携)、属性交換のための比較的ライトでオープンなプロトコル。 &quot; 認可 &quot; までてきない </li></ul></ul></ul><ul><ul><ul><li>OAuth = &quot; 認可 &quot; を目的とした、オープンなプロトコル。 &quot; 認可 &quot; に &quot; 認証 &quot; が前提になっているため、シングルサインオンにも使えてしまう </li></ul></ul></ul>
  14. 14. OpenID と OAuth <ul><ul><li>個人的に思うところ </li></ul></ul><ul><ul><ul><li>&quot; 属性交換 &quot; については、 OpenID AX でやるべきか、 OAuth の属性交換 API でやるべきか正直微妙 </li></ul></ul></ul><ul><ul><ul><li>API を使ってもらってなんぼ、の SP であれば OAuth を積極的に推進すべき </li></ul></ul></ul><ul><ul><ul><li>ID 連携、属性交換のみでいいのであれば、 OpenID で好きにやってもらう? </li></ul></ul></ul><ul><ul><ul><li>OpenID の拡張仕様で OAuth Extension があるので、将来的には既存の OpenID 対応サイトも OAuth を利用しやすくなる </li></ul></ul></ul><ul><ul><ul><li>OpenID CX など、契約ベースの属性交換を行うための拡張仕様が検討されており、今後 OpenID +決済が広まる可能性あり </li></ul></ul></ul>
  15. 15. OAuth 最近のトピック <ul><ul><li>セキュリティの脆弱性が発覚 </li></ul></ul><ul><ul><ul><li>セッション固定攻撃( OAuth Session Fixation Attack )への脆弱性( Session Fixation Security Advisory ?) </li></ul></ul></ul><ul><ul><ul><li>2009 年 4 月 23 日、メールやメッセで URL 送信するなどの Social Engineering の手法でユーザー本人に同意さえ踏ませれば、 API へのアクセス権限を不正利用者が乗っ取れてしまう脆弱性が発覚 </li></ul></ul></ul><ul><ul><ul><li>2009 年 6 月 24 日に、上記の問題を解決した &quot;OAuth Core 1.0 Revision A&quot; の仕様が策定され、解決済み </li></ul></ul></ul><ul><ul><ul><li>米 Yahoo! 、 Yahoo! JAPAN の OAuth は Revision A に対応した仕様で公開 </li></ul></ul></ul>
  16. 16. OAuth 最近のトピック <ul><ul><li>MobsterWorld の大量スパム DM 送信について </li></ul></ul><ul><ul><ul><li>2009 年 8 月 1 日頃から、 Twitter ユーザー間でソーシャルゲームアプリ &quot;MobsterWorld&quot; に関する特定の DM が意図せず多数送信されているという騒動が発生 </li></ul></ul></ul><ul><ul><ul><li>OAuth で同意した瞬間に、 MobsterWorld の Twitter アカウントを自動でフォローするとともに、そのユーザーの全 followers に同様の DM を一括送信してしまうというしくみ </li></ul></ul></ul><ul><ul><ul><li>DM 内に含まれる URL をクリックし、 MobsterWorld のサイトにアクセスした後にさらに進むと Twitter OAuth の同意画面が表示されるので、そこで &quot;Allow&quot; (同意)さえ押さなければ問題は発生しない </li></ul></ul></ul><ul><ul><ul><li>OAuth の同意画面上だけの説明では何が起こるか分からない、ユーザー自身も同意画面を慎重に読まない、といった点から生じた問題といえる(日本人ユーザーにとっては英語の説明だったことも少なからず影響) </li></ul></ul></ul>
  17. 17. セキュリティと OAuth <ul><ul><li>外部サイト上での ID 、パスワード入力 </li></ul></ul><ul><ul><ul><li>従来、 Web メールサービスのアドレス帳機能を外部サイトが利用する際に、ユーザー自身に直接 ID 、パスワードを入力させ、外部サイトのサーバがユーザーに成り代わってアクセス(スクレイピング)する行為が横行していた( Twitter では今も横行している) </li></ul></ul></ul><ul><ul><ul><li>本来、 ID とパスワードは外部サービスに渡しては絶対にいけないもの。決済ができるサービスや、センシティブな個人情報を扱うサービスでは特にそう </li></ul></ul></ul><ul><ul><ul><li>それをさせてしまっているサービスは、悪用しようと思えばいくらでも悪用できてしまうため、実質フィッシングに近い行為を行っていると思った方がいい </li></ul></ul></ul><ul><ul><ul><li>OAuth は、そういったセキュリティ上の問題を解決できるすばらしいソリューション </li></ul></ul></ul>
  18. 18. 妄想 <ul><ul><li>OAuth の SP 、 OAuth 対応 API が増えてほしい </li></ul></ul><ul><ul><ul><li>とにかく OAuth 対応 API がまだまだ少ないので、世にある Web サービスはどんどん OAuth やってほしい </li></ul></ul></ul><ul><ul><ul><li>OAuth の SP が増えれば増えるほど、マッシュアップサービスや○○アプリの可能性が広がる </li></ul></ul></ul><ul><ul><li>OAuth は Social と相性がいい </li></ul></ul><ul><ul><ul><li>ヒト単位のデータを受け渡すための OAuth と、ヒトをベースにしたソーシャル系サービスは相性がいい、と勝手に思っている。ソーシャル系のサービスこそガンガン API 出してほしい </li></ul></ul></ul><ul><ul><li>API 公開は後発サービスにこそ有効な戦略 </li></ul></ul><ul><ul><ul><li>強い No.1 がいる場合、それに追いつくために後発サービスは外部リソースでもなんでも利用して自サービスの価値向上を図る策が有効 </li></ul></ul></ul><ul><ul><ul><li>とにかく外部に面を増やす、サービスのデータを太らせる、自分で作れない機能を外部の開発者に作ってもらうなど </li></ul></ul></ul><ul><ul><li>Twitter OAuth </li></ul></ul><ul><ul><ul><li>Twitter はいま最も使われている Service Provider ( 2009 年 8 月時点) </li></ul></ul></ul><ul><ul><ul><li>Twitter OAuth により、 Twitter はいつのまにかに巨大 Identity Provider になっていた気がしてる </li></ul></ul></ul>
  19. 19. おまけ <ul><li>「 OAuth Core 1.0 Revision A 」を日本語訳してみた </li></ul><ul><li>  </li></ul><ul><li>http://d.hatena.ne.jp/tzmtk/20090723/p1 </li></ul>

×