パスワード氾濫時代のID管理とは？～最新のOpenIDが目指すユーザー認証の効率的な強化～

1. 工藤達雄 OpenIDファウンデーション・ジャパンパスワード氾濫時代のID管理とは？～最新のOpenIDが目指すユーザー認証の効率的な強化～

3. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. 自己紹介  工藤達雄 http://www.linkedin.com/in/tatsuokudo, @tkudos  サン・マイクロシステムズ (1998~2008) https://blogs.oracle.com/tkudo  野村総合研究所 (2008~)  OpenIDファウンデーション・ジャパン (2013~) http://openid.or.jp/blog

4. 不正アクセス対策としての「ID連携」

5. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. パスワード管理は限界にきている 3種類以下のパスワードを使いまわすユーザが約7割 / 2人に1人はパスワードを変更する習慣なし Source: トレンドマイクロ、2012年12月14日発表自分のIDでログインして利用するサイトの数は平均19.40 / 記憶できるIDとパスワードの組み合わせは平均3.15 Source: 野村総合研究所、2012年2月8日発表

7. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. ユーザー側に負担  対策として「サイトごとにパスワードを変える」  本当に可能だろうか?  パスワードマネージャーの導入  サイトごとのパスワードを自動生成し、ログインを支援するツール  ブラウザの標準機能としてサポートするケースも出てきたが… → いずれもユーザー側に対応を求めている「個人の利用者がパスワードリスト攻撃による最終的な被害者にならないようにするためには、すべてのインターネットサービスで異なるパスワードを設定する必要があります」 Source: 情報処理推進機構

8. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. 事業者側の対策の動向  2要素認証  大手サイトが相次いで導入している  しかし2要素認証を行なうサイトが多数乱立するようになるとユーザーにとっては不便  リスクベース認証  不正アクセスかどうかを判定し、必要に応じて高度認証を実施 → サービス側の導入・運用が容易ではない

9. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. 「Webアプリケーションのユーザー認証・認可」をシーケンスとして考えてみる 1 2 3 7 4 5 8 9 2. 「ログインしてください」 3. ID/パスワードを入力 1. アクセス試行 4. ID/パスワードを照合アプリケーション ID情報 DB ユーザー 5. 照合OK （属性を返却） 7. ユーザーに応じたサービスを提供 8. アクセス試行（ログイン済み） 9. ユーザーに応じたサービスを提供 6 6. アクセス認可決定

10. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. サービスが個別にユーザー認証・認可を行なう 2 3 7 4 5 3. ID/パスワードを入力アプリケーションA ID情報 DB ユーザー 6 1 9 10 14 11 12 10. ID/パスワードを入力 ID情報 DB 13 8 アプリケーションB 2. 「ログインしてください」 9. 「ログインしてください」

11. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. 事業者による個別対応は、ユーザーの利便性をさらに下げることに 2 3 7 4 5 3. ID/パスワード、 OTP、… アプリケーションA ID情報 DB ユーザー 6 1 9 10 14 11 12 10. ID/パスワード、厳しいパスワードポリシー、… ID情報 DB 13 8 アプリケーションB ユーザー認証プロセス、パスワードポリシー、認証に必要なデバイスの管理などが、サイトごとにバラバラ

12. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. アイデンティティ&アクセス管理（IAM）システムを導入し、ユーザー認証・認可を一元化する 2 3 7 4 5 アプリケーションA ID情報 DB ユーザー 6 1 9 3. ID/パスワードを入力 8 アプリケーションB 2. 「ログインしてください」 4. ID/パスワードを照合 5. 照合OK （属性を返却） 6. アクセス認可決定 IAMシステム 1. アクセス試行 7. ユーザーに応じたサービスを提供 8. アクセス試行 9. ユーザーに応じたサービスを提供

13. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. IAMの利点と限界  効率的にセキュリティの向上を図ることができる  タイムリーなアカウント改廃、サービス全体を統一するユーザー認証・認可、パスワードポリシー、不正アクセス検知機能などの統合  ユーザーにとっての利便性が高まる  シングル・サインオン、プロファイル情報の共通化  しかし、基本的には同一企業グループ内でしか使えない  グループ企業であっても、ビジネス的に統合できないケースも

15. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. ID（アイデンティティ）連携: ユーザーの同意にもとづくID情報の要求・提供アプリケーションA アプリケーションB ID情報 DB ユーザー A社 B社 ID情報 DB 1 2 4 5 6 11 3 8 7 9 10 14 12 13 15 3. 「ログインしてください」 4. ID/パスワードを入力 1. アクセス試行 2. 認証リクエスト 11. 認証レスポンス（ID情報） 5. ID/ パスワードを照合 6. 照合 OK 9. 属性取得 10. 属性提供 7. 「ID情報提供OK?」 8. ユーザーによる同意 15. ユーザーに応じたサービスを提供 12. 認証レスポンスに基づきユーザーを特定し属性情報を要求 13. 属性取得 14. アクセス認可決定

16. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. ID（アイデンティティ）連携のポイント  ID情報（認証結果、属性情報）が連携される  パスワードのような秘密情報は流れない  ユーザーの同意に基づいて行われる  サービス同士が勝手にやりとりするのではない  各サービスの独立性が保たれる  外部から取得したID情報を用いてどのようにアクセスを認可するかは各サービスの判断に委ねられる → システム的にもビジネス的にも有利

17. ID連携技術概要（SAML、OpenID、OAuth）

18. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. ID（アイデンティティ）連携を実現する技術仕様  技術仕様では、ID情報をどうやって要求・提供するか（プロトコル）、それはどういう表現か（メッセージ形式）を規定  プロトコル: フロントチャネル（Webブラウザ等でのリダイレクトによる間接通信）、バックチャネル（サーバー間の直接通信）、…  メッセージの形式: XML、JSON、URLパラメーター、…  普及しているオープン仕様は主に4種類  SAML（サムル）  OpenID（オープンアイディー）  OAuth（オーオース）  OpenID Connect（オープンアイディー・コネクト） 1 2 4 3 5 2. 認証リクエスト 4. 認証レスポンス（ID情報 or 「引換証」） ID情報提供側 ID情報要求側ユーザー 1. アクセス試行 5. サービス提供 3. 認証・同意 4’ 4’. 「引換証」を送信 4’’ 4’’. 認証レスポンス（ID情報）

19. Source: http://www.cafepress.com/oasis_open.20273829

20. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. SAML (サムル; Security Assertion Markup Language)  アイデンティティ情報を安全に流通させるためのXML形式および通信仕様  ID連携を実現する主要要素を 4つに分解  「アサーション」「プロトコル」「バインディング」「プロファイル」 Profile 特定のユースケース（SSOなど）を実現するうえでの、アサーション、プロトコル、バインディングの組み合わせを規定。 Binding リクエストおよびレスポンスの手続きを、実際にIdP とRPの間でどのように実施するか規定。直接通信（SOAP）や、ユーザエージェントを介在させる HTTPリダイレクト通信などが存在。 Protocol アサーションの送受信を実施するためのリクエストおよびレスポンスの手続き。 Assertion ユーザのID名や認証方法およびそのユーザの属性や権限に関する表明。

21. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. SAML 2.0 Web Browser SSO Profile Webアプリケーション間のSSO向けのプロファイル 1 2 4 3 5 2. 認証リクエスト <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0: assertion" Version="2.0" IssueInstant="2005-01-31T12:00:00Z"> <saml:Issuer>www.example.com</saml:Issuer> <saml:Subject> <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid- format:emailAddress">j.doe@example.com</saml:NameID> </saml:Subject> <saml:Conditions NotBefore="2005-01-31T12:00:00Z" NotOnOrAfter="2005-01-31T12:30:00Z"></saml:Conditions> <saml:AuthnStatement AuthnInstant="2005-01-31T12:00:00Z" SessionIndex="0"> <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes: PasswordProtectedTransport </saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> </saml:Assertion> ID情報提供側 (Identity Provider) ID情報要求側 (Service Provider) ユーザー 1. アクセス試行 5. サービス提供 3. 認証・同意 4’ 4’. 「アーティファクト」を送信 4’’ 4’’. 「アサーション」 4. 認証レスポンス（「アサーション」 or 「アーティファクト」）アサーションの例

22. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. SAMLの普及動向  Google AppsやSalesforce.comなどのSaaS提供事業者が、利用企業との間の ID連携のベースとして採用  SaaS契約企業の社員が、社内SSO（シングル・サインオン）でユーザー認証を受け、社外のSaaSにログイン  その他、B2B（業務目的での企業間連携）や、高等教育機関でのフェデレーション・ネットワークのベースとして採用  cf. Global Trust Framework Survey - DG - Business Cases for Trusted Federations - Kantara Initiative http://kantarainitiative.org/confluence/display/bctf/Global+Trust+Framework+Survey  ただし、フェデレーション要件に応じてSAML仕様をどう使うか取り決める（プロファイリング）必要があるため、フェデレーション・ネットワーク間の相互運用性は低い

23. Source: http://openid.net/images/logo/openid-icon-1000x1000.png

24. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. SAMLの代替としてのOpenIDの登場  「Webサイト間のID連携」に特化し、Webサイト開発者にとって使いやすい仕様にした  SAMLは包括的なフレームワークであるがゆえに複雑  「ユーザーセントリック・アイデンティティ」（ユーザーによるID連携のコントロール）を仕様に盛り込んだ  SAMLは事業者中心のモデル

25. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. 「OpenID 2.0」  ふたつのWebサイト間における、Webブラウザを用いたID情報の要求・提供を行うためのプロトコルとして、2007年12月に策定  認証結果の要求・取得: OpenID Authentication 2.0  属性情報の要求・取得: Attribute Exchange (AX) Extension 1.0  認証ポリシーの公告・要求・表明: Provider Authentication Policy Extension (PAPE) 1.0  ユーザー認証・同意ページのユーザー・インタフェースの指定: OpenID User Interface Extension 1.0 （Draft)  OpenID AuthenticationとOAuth 1.0のハイブリッド: OpenID OAuth Extension (Draft)

26. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. OpenID の概念と登場人物  ユーザがアイデンティティ (ID) 情報の提供サイトを選択（実際にはホワイトリスト運用が一般的）  OpenID プロバイダ (OP): ID 情報 (認証結果や属性情報) を RP に提供するサイト  OpenID リライング・パーティ (RP): OP から提供された ID 情報を受け入れるサイト RP (医療情報管理サービス) 「本人以外には決して公開しない」 RP (無料日記サービス) 「誰でも気軽にコメントしてほしい」 RP(ホテル予約サービス) 「確かな属性情報がほしい」 OP(ポータルサイト) 誰でも即時アカウント取得可能 OP(航空券予約サービス) クレジットカード番号等を管理 OP(高度認証サービス) 登録時に厳密な本人確認を行ない、多要素認証を実施 ID / パスワードでログイン ID情報の提供 ID / 画像認証でログイン ICカードの証明書でログイン ID情報の提供 ID情報の提供クレデンシャル情報（ID/PW等）の入力によるユーザの特定はOP側で行うため、RP側にクレデンシャル情報を流通させる必要がない OP：ID情報の提供側 RP：ID情報の受入側

27. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. OpenID Authentication 2.0 1 3 5 4 6 3. 認証リクエスト ID情報提供側 (OpenID Provider) ID情報要求側 (Relying Party) ユーザー 1. アクセス試行 6. サービス提供 4. 認証・同意 2 2. 動的に署名鍵を共有 openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0 openid.mode=id_res openid.return_to=*** openid.claimed_id=https%3A%2F%2Fexample.jp%2F050af1f6-4547-4cc2-9e55- 78337e5c9156 openid.identity=https%3A%2F%2Fexample.jp%2Fa%2F050af1f6-4547-4cc2-9e55- 78337e5c9156 openid.assoc_handle=*** openid.realm=*** openid.ns.ax=http%3A%2F%2Fopenid.net%2Fsrv%2Fax%2F1.0 openid.ax.mode=fetch_res%2Cax.value.genderponse openid.response_nonce=*** openid.signed=assoc_handle%2Cclaimed_id%2Cidentity%2Cmode%2Cns%2Cop_endpoint %2Cresponse_nonce%2Creturn_to%2Csigned%2Cns.ax%2Cax.mode%2Cns.pape%2Cpape.au th_policies%2Cpape.auth_level.ns.nist%2Cpape.auth_level.nist openid.op_endpoint=https%3A%2F%2Fop.example.jp%2F openid.ax.type.gender=http%3A%2F%2Faxschema.org%2Fperson%2Fgender openid.ns.pape=http%3A%2F%2Fspecs.openid.net%2Fextensions%2Fpape%2F1.0 openid.pape.auth_policies=http%3A%2F%2Fschemas.openid.net%2Fpape%2Fpolicies% 2F2007%2F06%2Fnone openid.pape.auth_level.ns.nist=http%3A%2F%2Fcsrc.nist.gov%2Fpublications%2Fn istpubs%2F800-63%2FSP800-63V1_0_2.pdf openid.pape.auth_level.nist=0 openid.sig=*** 5. アサーション（一部略）

28. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. OpenID 2.0の普及動向  多数のユーザを抱えるWebサイトが、他社WebサイトにID情報を提供するための API（Application Programming Interface）としてOpenIDを採用  インターネットサービス事業者（例： Yahoo!、Google、ミクシィ）  携帯通信事業者（例： NTTドコモ、KDDI、ソフトバンク）  ネット決済事業者（例：楽天（楽天あんしん支払いサービス）、PayPal）  公共性の高いサービスでのOpenIDの採用  米国において、民間のIdP (Identity Provider：たとえばポータル事業者や決済事業者など、市民に対してID を発行・運用する組織)と、連邦政府機関の市民向けWeb サイトとのID連携プロトコルの一つとして採用

29. Source: http://oauth.net/2/

30. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. ユーザーの代理としてWeb APIにアクセスするクライアントのアクセス認可をどのように実現するか  「ユーザーのID/パスワード」を預かる方法が広まってしまったが…  ユーザーはサービスBのID/パスワードをサービスAに漏らしている ▪ サービスAの情報漏えいや、サービスA自身による不正利用の懸念が残る  ユーザーはサービスAに全権委任するかたちに ▪ サービスAは本来不要な（過剰な）API アクセスを行うこともできてしまう  使い勝手が悪い ▪ サービスBのID/パスワードを変更すると、サービスAがアクセスできなくなる ▪ サービスAからサービスBへのアクセス可能期間を指定できない 1 4 サービスB （API提供側）サービスA （API利用側）ユーザー 1. サービスBにある自身のコンテンツを参照するために、ユーザーがサービスBにおけるID/パスワードを提供 4. サービスBのコンテンツをもとにサービスを提供 2 2. サービスAが、サービスBのID/ パスワードを用いて代理ログインし、 APIにリクエストを送信 3 3. サービスBのユーザーであるとみなし、処理結果を返却

31. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. OpenIDをAPIのアクセス認可にも使えないか?  2006年11月、TwitterのエンジニアやOpenIDコミュニティを中心に、API代理認証にOpenIDを適用できないか議論が始まった。結果的にOpenIDは適用できず、また当時API代理認証のオープン標準と呼べるものはまだ存在しないことが明らかになった。  2007年4月、少人数にてプロトコル検討が始まり、7月には仕様草案の初版をもとに公開の場にて議論されるようになった。そして10月、OAuth 1.0の最終ドラフトが公開された。 Source: http://oauth.net/about/

32. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. OAuthの登場  「トークン」による API アクセス制御  トークン: ユーザーに成り代わってアクセスすることを示す符号  「API プロバイダーがユーザーを直接認証するフロー」が普及  APIクライアントにID/パスワードをもらさずに済む  API 提供側はユーザー単位でのアクセス管理が可能 ▪ トークンはユーザーとひもづいている 1 2 4 3 7 2. 認可リクエスト認可サーバー/ リソースサーバー API クライアントユーザー 1. アクセス試行 7. サービス提供 3. 認証・同意 4’ 4’. 「認可コード」を送信 4’’ 4’’. 「アクセストークン」 4. 認可レスポンス（「認可コード」 or 「アクセストークン」） 5 5. API アクセス with アクセストークン 6 6. APIレスポンス

33. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. OAuthの普及動向  APIアクセス認可の事実上の標準フレームワークとして広く普及  ソーシャル・ネットワーク: Facebook, Twitter, ミクシィ, Google+, GREE, Ameba, Windows Live, LinkedIn, …  エンタープライズ: Google Apps, Microsoft Office 365, Salesforce.com, …  EC/決済/ポイント: 楽天、Yahoo!、PayPal、カラーミーショップ、Amazon.com、サントリー、リクルート、…  パーソナル・クラウド: Dropbox、Evernote、…  銀行/証券: AXA Banque, E*TRADE, Capital One, …  通信事業者: NTTドコモ  テレマティクス: GM OnStar  ゲーム: スクエアエニックス、虎の穴、エイチーム、EA、…  スマートグリッド：会津若松スマートシティ推進協議会  その他多数

34. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. OAuth仕様には「ID情報」の扱い方は書かれていない  アクセストークンは「権限が移譲されたことを示す情報」であり、認証結果や属性情報ではない  実運用ではアクセストークンに加えてID情報も扱うよう独自拡張を行なうケースが多い  認可リクエストに要求属性を指定  「アクセストークンレスポンス」にID情報を示すキー/値を追加  アクセストークン自体を構造化し、ID情報を包含  アクセストークンを受け取ってID情報を返却する APIを提供 { "access_token":"mF_9.B5f-4.1JqM", "token_type":"Bearer", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA" } アクセストークン（レスポンス）の例 1 2 4 3 7 2. 認可リクエスト認可サーバー/ リソースサーバー API クライアントユーザー 1. アクセス試行 7. サービス提供 3. 認証・同意 4’ 4’. 「認可コード」を送信 4’’ 4’’. 「アクセストークン」 4. 認可レスポンス（「認可コード」 or 「アクセストークン」） 5 5. API アクセス with アクセストークン 6 6. APIレスポンス

35. 最新のID連携仕様 “OpenID Connect”

36. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. SAML、OpenID、OAuthではダメなのか!? Pros Cons SAML •仕様がモジュール化されており、拡張性が高い •署名や暗号化などを用いてセキュリティを強化できる •仕様群が膨大 •XMLの検証や署名、暗号化などが複雑であり、実装が容易ではない •RESTful APIとはなじまない OpenID •認証結果と属性情報の要求・提供に機能を限定して標準化されており、相互接続性が高い •鍵共有、署名の付与・検証が面倒 •平文のID情報がWebブラウザ経由で流れるため、内容が露見 •APIアクセス認可への応用は不可能 OAuth •他の仕様と比較してシンプル •スコープによるアクセス権限指定、 Authorizationヘッダの利用など、「RESTful API」との親和性が高い •Webブラウザだけではなく、モバイルネイティブやJavaScriptなど、モダンなクライアント環境を考慮している •認証結果と属性情報の要求・提供が定義されておらず、事業者の独自拡張が乱立 1 2 4 3 5 2. 認証リクエスト 4. 認証レスポンス（ID情報 or 「引換証」） ID情報提供側 ID情報要求側ユーザー 1. アクセス試行 5. サービス提供 3. 認証・同意 4’ 4’. 「引換証」を送信 4’’ 4’’. 認証レスポンス（ID情報）

37. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. OpenID Connect リライング・パーティ (RP: ID情報要求側) Webアプリケーションモバイルアプリケーションライブラリやパッケージの導入が不要ネイティブ (non-Web) アプリでも利用可能認証結果/属性情報提供 JWT * によってセキュアにID情報を提供 * JSON Web Token アイデンティティ・プロバイダ (IdP: ID情報提供側) SSO / アクセス管理システム “Self-issued IdP” OpenID Connect 対応製品が続々登場携帯端末が IdPに!  OAuth 2.0仕様をベースに「アイデンティティ層」を拡張し、認証結果や属性情報の連携、セッション管理などのAPIを標準化認可リクエスト/APIアクセス OAuth 2.0による API認可と統合

38. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. 主要ID/API連携仕様がすべてOpenID Connectに収斂 Source: http://civics.com/OpenID-connect-webinar/ セキュリティ・アサーション JSON形式の「IDトークン」サービス発見シンプル、APIとの親和性、モバイル対応動的なクライント登録

39. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. アイデンティティ連携関連仕様の比較比較項目＼仕様 SAML 2.0 OpenID 2.0 OAuth 2.0 OpenID Connect ID受け入れ側（リライング・パーティ）の実装・運用の容易さ ×（XMLやSOAP、PKIなどのスキルが必要であり、通常はSAML処理ライブラリやミドルウェアの導入が必須） △（鍵交換や署名処理が必要であり、通常はOpenID処理ライブラリなどの導入が必須） ○（ライブラリ等の導入が不要） ○（ライブラリ等の導入が不要） Webブラウザ以外（デスクトップアプリ、スマートフォンアプリなど）への対応 △（仕様上はWebブラウザ以外にも対応可能だが、実際に広く利用されているのは Web SSOのみ） ×（Webブラウザのリダイレクト機能に依存したプロトコルであり、Webブラウザ以外への対応は不可能） ○ ○ 認証結果の連携 ○ ○ ×（仕様外であり、OAuth採用事業者の独自拡張が乱立） ○ 属性情報の連携 ○ ○ ×（仕様外であり、OAuth採用事業者の独自拡張が乱立） ○ APIアクセス認可（アクセストークン配布）への対応 ×（仕様のスコープ外） △（OAuth 1.0とのハイブリッドにより対応） ○ ○ 複数のアクセストークンへの対応 ×（仕様のスコープ外） ×（仕様のスコープ外） ×（仕様のスコープ外） ○ 認証結果・属性情報への署名や暗号化 ○ △（共有鍵による署名のみ可能。暗号化は仕様のスコープ外） ×（そもそも、認証結果・属性情報の連携は仕様のスコープ外） ○ サイト間のセッション管理 ○ ×（仕様のスコープ外） ×（仕様のスコープ外） ○ 機能の不十分なWebブラウザ（携帯電話等）への対応 × × ○ ○ 備考さまざまなユースケースに適用可能な仕様であるが、それゆえに複雑であり、結果的には企業内ID管理システムと企業向けSaaS との間でのSSOに利用されるにとどまっている。 Webサイト間の認証結果・属性情報の交換に特化したプロトコルであり、従前の仕様（SAML 2.0)に比較して単純なプロトコルであるが、鍵交換や署名処理など、まだ実装が容易ではない点が残る。 OAuth 1.0をベースに、より容易に実装できるように仕様を簡略化。Web APIのアクセス認証プロトコルとして広く普及。しかしD連携に関してはスコープ外であり、独自仕様が乱立している。 OAuth 2.0をベースに、ID連携のためのプロトコルを定義。OAuth 2.0の実装のしやすさを活かしつつ、ID連携に十分な機能を定義している。

40. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. OpenID ConnectによるID連携のしくみ  ユーザーの認証イベント（認証結果）を「IDトークン」として定義  OAuth 2.0と同一のフローにて、「アクセストークン」に加え、新たに「IDトークン」の要求・提供を定義  また、属性情報を提供する「ユーザー情報（UserInfo） API」を定義 1 2 4 3 7 2. 認可リクエスト ID情報提供側（アイデンティティ・プロバイダ） ID情報要求側（リライング・パーティ）ユーザー 1. アクセス試行 7. サービス提供 3. 認証・同意 4’ 4’. 「認可コード」を送信 4’’ 4’’. 「アクセストークン」「IDトークン」 4. 認可レスポンス（「認可コード」 or 「アクセストークン」「IDトークン」） 5 5. UserInfo アクセス with アクセストークン 6 6. 属性情報

41. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. IDトークン  ID情報提供側におけるユーザ認証イベントの情報を含む、署名付きJWT（Signed JSON Web Token）  「このエンドユーザーは○○で、何時何分に、こういう方法で認証を受け、認証レベルは○で、…」  ID情報要求側は主に、IDトークンに含まれる以下のクレーム（ID情報提供側がユーザーに関して表明する情報）を用いて、エンドユーザーのアクセス認可を行う  エンドユーザーを識別する値（識別子）  IDトークンの有効期限  ユーザ認証を実施した日時  認証コンテクスト・クラス・リファレンス  認証手段リファレンス  その他（ユーザー属性など） { "iss": "http://server.example.com", "sub": "248289761001", "aud": "s6BhdRkqt3", "nonce": "n-0S6_WzA2Mj", "exp": 1311281970, "iat": 1311280970, "name": "Jane Doe", "given_name": "Jane", "family_name": "Doe", "gender": "female", "birthdate": "0000-10-31", "email": "janedoe@example.com", "picture": "http://example.com/janedoe/me.jpg" } IDトークンの中身の例 1 2 4 3 7 2. 認可リクエスト ID情報提供側（アイデンティティ・プロバイダ） ID情報要求側（リライング・パーティ）ユーザー 1. アクセス試行 7. サービス提供 3. 認証・同意 4’ 4’. 「認可コード」を送信 4’’ 4’’. 「アクセストークン」「IDトークン」 4. 認可レスポンス（「認可コード」 or 「アクセストークン」「IDトークン」） 5 5. UserInfo アクセス with アクセストークン 6 6. 属性情報

42. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. OpenID Connect仕様の現状と今後  2014年2月に「OpenID Connect」仕様の最終版が承認  コア機能、ディスカバリー、動的クライアント登録など  最終版の承認以前から、すでに複数の製品・サービスがOpenID Connectを実装済み  製品: 野村総合研究所（Uni-ID）、日本電気（NC7000-3A)、NTTソフトウェア（TrustBind Federation Manager）、Ping Identity （PingFederate）、Gluu (OX)、CA (Layer 7)、 ForgeRock (OpenAM)  サービス: Yahoo! JAPAN (YConnect)、日本経済新聞社（日経ID）、東急電鉄、テレビ東京、 Google、PayPal (Log In with PayPal)、東芝 (Cloud TV) 、ソフトバンクモバイル (My SoftBank)、ミクシィ、Salesforce.com、Microsoft  その他、セッション管理などの関連仕様が、最終版を目指して策定中

43. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. 仕様の最終版承認を受け、主要IDプロバイダーにおいて OpenID Connectへの移行が活発化  Google: 従来の自社独自の認証認可仕様を非推奨とし、 OpenIDとOAuthに移行。さらに将来的にはこれらを廃止してOpenID Connectに統一することを表明  Salesforce.com: 従来のSOAP APIは自社独自の認証認可仕様を用いていたが、新たなRESTful APIはOAuthとOpenID Connectに統一  PayPal: 従来のAPIは自社独自の認証認可仕様を用いていたが、OpenID、OAuth、OpenID Connectに移行中。この中でもとくにOpenID Connectの利用を推奨  Microsoft: これまでは自社が中心となって策定したWS- Federationの普及を目指していたが、今後の主力サービスであるWindows LiveやWindows AzureにはOAuthを採用。 OpenID Connect対応が進行中 … we’re also going to consolidate all our federated sign-in support onto the OpenID Connect standard. … we will deprecate support for our older federated sign-in protocols including OpenID 2.0 on April 20, 2015, and our early version of OAuth 2.0 for Login, including the userinfo scopes and endpoint, on September 1, 2014. Googleは2015年4月までにOpenID Connect以外のIDの連携APIを終了予定 Source: Google Developer Blog

44. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. ID管理・ユーザー認証・属性提供のサービス化 (IDaaS; Identity as a Service) ユーザー “IDaaS” •Google •Microsoft •Salesforce.com •PayPal •… サービス OpenID Connectによって認証を依頼 IDプロバイダーの IDでログインサービス利用 IDプロバイダーにユーザー認証を委ねることにより、自前で行なうよりもより高度な不正アクセス対策が活用できるふだん使い慣れているID でサービスが利用可能になり、利便性が向上し、またサービスへのパスワード登録が不要となることもユーザーの不安の解消につながる IDaaS活用の業界標準API = OpenID Connect

45. まとめ

46. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. まとめ  ユーザー認証強化をビジネスを考慮しつつ効率的に実現するためには、 ID（アイデンティティ）連携が有効  ID連携技術の標準はこれまで複数存在していたが、業界はOpenID Connectへの統一に向かっている  今後はOpenID Connectによるユーザー認証の外部化も選択肢のひとつに

47. Copyright © 2014 OpenID Foundation Japan. All Rights Reserved. リソース  OpenIDファウンデーション・ジャパン http://www.openid.or.jp/  OpenID関連情報の提供やセミナーの開催  会員企業同士の活動 ▪ワーキンググループを通じた、業界イニシアティブへの参画 ▪企業や業界を超えた標準仕様の作成や、ビジネスモデルの創出に関する検討 ▪IDを軸とする会員企業間のコラボレーション ▪技術者コミュニティや会員企業間の情報交換を通じた、OpenID関連の技術情報、ビジネストレンド情報の入手 ▪会員企業限定のセミナー、交流会（ネットワーキング）、フォーラムへの参加

http://www.slideee.com	6
https://cybozulive.com	6
https://twitter.com	2
http://www.linkedin.com	1
http://s.deeeki.com	1

SlideShare for iOS

パスワード氾濫時代のID管理とは？～最新のOpenIDが目指すユーザー認証の効率的な強化～

by Tatsuo Kudo , A Digital Identity Professional at NRI SecureTechnologies

on May 19, 2014

Statistics

Views

Actions

5 Embeds 16

Accessibility

Categories

Upload Details

Usage Rights

Report content