• Save
YAPC::Tokyo 2013 ritou OpenID Connect
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

YAPC::Tokyo 2013 ritou OpenID Connect

  • 6,006 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
6,006
On Slideshare
3,312
From Embeds
2,694
Number of Embeds
14

Actions

Shares
Downloads
0
Comments
0
Likes
15

Embeds 2,694

http://d.hatena.ne.jp 1,325
http://yapcasia.org 1,154
http://www.openid.or.jp 160
https://twitter.com 27
http://cloud.feedly.com 13
http://webcache.googleusercontent.com 2
http://www.google.co.jp 2
http://feedly.com 2
http://digg.com 2
http://translate.googleusercontent.com 2
http://plus.url.google.com 2
http://www.feedspot.com 1
http://openid.or.jp 1
http://summary 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. OpenID Connect これが最新のOpenID仕様だッ! Ryo Ito (@ritou) YAPC::Asia Tokyo 2013
  • 2. 自己紹介 ● Ryo Ito (@ritou) ○ 株式会社ミクシィ 研究開発グループ ○ OpenID ファウンデーション・ジャパン エヴァンジェリスト ○ http://d.hatena.ne.jp/ritou/ ○ @IT デジタル・アイデンティティ技術最新動向 「OpenID Connect」を理解する http://www.atmarkit.co. jp/ait/articles/1209/27/news138.html
  • 3. 1. OpenID Connectとは?
  • 4. OpenIDとOAuthの違い ● OpenID : 異なるサービス間でユーザーの認証 情報をやりとりする仕様 ● OAuth : 異なるサービス間でAPIアクセスを実 現するしくみ
  • 5. アイデンティティ技術のトレンド ● Webアプリ間でアカウント連携 ○ OpenID 2.0 ○ 2008年頃から ● Webアプリ間のAPI連携 ○ OAuth 1.0 ○ 2009年頃から ● Webアプリ + ネイティブアプリ間のAPI連携 ○ OAuth 2.0 ○ 2010年頃から
  • 6. OAuth認証とは ● OAuthはAPIアクセスのための仕様だが・・・ ● プロフィールAPIでユーザー識別子を取得して SSOに使っちゃおう!!!的な発想
  • 7. OAuth認証とは ● OAuthはAPIアクセスのための仕様だが・・・ ● プロフィールAPIでユーザー識別子を取得して SSOに使っちゃおう!!!的な発想 ○ 独自API ○ OAuth 2.0ではモバイルアプリに広く使われるフローで セキュリティリスクが発生
  • 8. OpenID Connectとは ● OAuth 2.0をベースに, アイデンティティ層を拡 張した仕様 ○ 認証結果の受け渡し + APIアクセス認可を同時に行う ● OpenIDファウンデーションで仕様策定中 ○ 現在Implementer's Draft ○ 日本人も関わっている
  • 9. 難しそう? ミニマムな実装としては, 下記の2点だけ ● ID Tokenで認証/認可情報を受け渡し ● 標準的な属性情報提供API
  • 10. Source : http://www.atmarkit.co.jp/ait/articles/1209/27/news138.html OPにリダイレクトして同意
  • 11. Source : http://www.atmarkit.co.jp/ait/articles/1209/27/news138.html POST リクエストを送り、 アクセストークンと ID Tokenを取得
  • 12. Source : http://www.atmarkit.co.jp/ait/articles/1209/27/news138.html メールアドレスなど 属性情報を取得
  • 13. 認証/認可の情報を含むID Token ● 認可情報 ○ どこの : OP識別子 ○ だれが : ユーザー識別子 ○ いつ : タイムスタンプ ○ どこに : RP識別子 ● 認証の情報 ○ 認証時刻 ○ 認証方式
  • 14. トークン文字列はJSON Web Token形式 eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9 . eyJpc3MiOiJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsIn N1YiI6IjI0NDAwMzIwIiwiYXVkIjoiczZCaGRSa3F0MyIsIm5v bmNlIjoibi0wUzZfV3pBMk1qIiwiZXhwIjoxMzExMjgxOTcwL CJpYXQiOjEzMTEyODA5NzAsImF1dGhfdGltZSI6MTMxM TI4MDk2OSwidHlwIjoiSldUIn0 . LbJA_DmSR5R3Sa79xqtG9sU8uy1Sm8KG1V8VBJOby4E
  • 15. トークン文字列はJSON Web Token形式 eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9 ↑メタデータをBase64 URL エンコードしたもの . ←ピリオドで連結 eyJpc3MiOiJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsIn N1YiI6IjI0NDAwMzIwIiwiYXVkIjoiczZCaGRSa3F0MyIsIm5v bmNlIjoibi0wUzZfV3pBMk1qIiwiZXhwIjoxMzExMjgxOTcwL CJpYXQiOjEzMTEyODA5NzAsImF1dGhfdGltZSI6MTMxM TI4MDk2OSwidHlwIjoiSldUIn0 ↑送りたいデータをBase64 URL エンコードしたもの . LbJA_DmSR5R3Sa79xqtG9sU8uy1Sm8KG1V8VBJOby4E ↑署名をBase64 URLエンコードしたもの
  • 16. ユーザーの属性情報を提供するAPI scopeの値に関連付けられた属性情報を提供 ● openid : ユーザー識別子 ● profile : プロフィール情報 ● email : メアド + 確認状態 ● phone : 電話番号 + 確認状態 ● address : 住所情報
  • 17. その他 ● 動的なRP登録, 探索 ● ユーザー認証周りのリクエストパラメータ ● 署名つき/暗号化されたリクエスト ● 属性情報の集約/分散
  • 18. モバイル端末とIdentity モバイル端末自体の識別はけっこう難しい ● デバイス固有な識別子? ○ かんたんログインのセキュリティ/プライバシー問題 ● ある程度セキュアな領域は提供されている ○ iOS KeyChain ○ Android KeyStore
  • 19. Self-Issued OP : デバイス内OP モバイル/WebアプリはカスタムURIスキームにて リクエストを送信 ● openid:// 端末内でOPとして動作するアプリ or Native機能 がOPとなる ● デバイス内でユニークな鍵ペアを生成 ● 公開鍵をPayloadに含む ● 秘密鍵で署名してID Tokenを作成
  • 20. Self-Issued OP : デバイス内OP 利用するモバイル/Webアプリのメリット ● 公開鍵のハッシュ値から、どの端末を利用して いるかを識別可能 ● タイムスタンプ/署名により改ざんが難しい ● ユーザーの同意を得るしくみがある
  • 21. Self-Issued OP : デバイス内OP いくつか課題が残っている ● 信頼性(OS機能じゃないとNG?) ● 名寄せ防止のための複数の鍵ペア生成 ネイティブアプリを作っていてより厳密なデバイス 識別をやりたいところは使えると思う
  • 22. 2. OIDC::Lite
  • 23. OIDC::Lite ● OAuth 2.0のServer/Client向けライブラリであ るOAuth::Lite2を拡張 ● https://metacpan.org/module/OIDC::Lite ● https://github.com/ritou/p5-oidc-lite
  • 24. Source : http://www.atmarkit.co.jp/ait/articles/1209/27/news138.html
  • 25. RP(Client)向け機能 ● 認可要求のURL生成 ● アクセストークン、IDトークンの要求 ● レスポンスの検証 LWP使って手動でリクエストを書き, レスポンスを JSONデコードするよりは楽
  • 26. OP(Server)向け機能 ● 各エンドポイント毎に”一連の手続き”を実装 ● Authorization Endpoint ○ リクエストパラメータの検証 ○ ユーザー同意/拒否後のレスポンス生成 ○ 同意画面表示のあたりで上記メソッドを使う ● Token Endpoint ○ 各grant_type単位の処理を実装 ○ psgiアプリケーション ● Protected Resource ○ Access Tokenを検証しユーザーIDなどをAPIに必要な 値を環境変数にセット ○ PlackのMiddleware
  • 27. OP(Server)向け機能 利用者が行うこと ● Access Token(アクセストークン), AuthInfo(認 可情報)の保存部分などを実装 ○ あらかじめ用意されているのはアクセサのみ ○ DBに入れたりキャッシュに保存したり ● DataHandlerに定義されている処理を実装 ○ client_idなどの検証 ○ 上記クラスの生成/更新処理
  • 28. 難しそう? ● サンプルOP/RP作りました ○ https://github.com/ritou/p5-oidc-lite-demo-server ○ https://github.com/ritou/p5-oidc-lite-demo-client ● デモ ○ http://demo-client.openidconnect.info/ ○ http://demo-server.openidconnect.info/ ● ブログエントリも書きました ○ http://d.hatena.ne.jp/ritou/
  • 29. サンプルOP/RP ● 目的 ○ ライブラリの使い勝手を確認 ○ OP/RPの実装例を公開 ○ 誰でもInterop! ● carton install + plackupで簡単に起動
  • 30. サンプルOP : Authorization Requestの表示
  • 31. サンプルOP : Authorization Responseの表示
  • 32. サンプルRP : Access Token Req/Resの表示
  • 33. サンプルRP : ID Tokenの内容/属性情報の表示
  • 34. まとめ ● OpenID Connect ○ OAuth 2.0にIdentity層を追加する拡張 ○ ミニマムな実装はID Tokenと属性提供API ○ Self-Issued OPでデバイス特定 ● OIDC::Lite ○ OAuth::Lite2を拡張したOP/RP向けライブラリ ○ サンプルOP/RPもあります
  • 35. 終わり OpenIDやOAuthについての質問や疑問がありま したら @ritou までお気軽に声をかけてください!!!