• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
YAPC::Tokyo 2013 ritou OpenID Connect
 

YAPC::Tokyo 2013 ritou OpenID Connect

on

  • 5,152 views

 

Statistics

Views

Total Views
5,152
Views on SlideShare
2,715
Embed Views
2,437

Actions

Likes
11
Downloads
0
Comments
0

13 Embeds 2,437

http://d.hatena.ne.jp 1294
http://yapcasia.org 938
http://www.openid.or.jp 156
https://twitter.com 24
http://cloud.feedly.com 13
http://feedly.com 2
http://www.google.co.jp 2
http://plus.url.google.com 2
http://digg.com 2
http://translate.googleusercontent.com 1
http://summary 1
http://openid.or.jp 1
http://www.feedspot.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    YAPC::Tokyo 2013 ritou OpenID Connect YAPC::Tokyo 2013 ritou OpenID Connect Presentation Transcript

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