PDSを実現するにあたっての技術動向の紹介 (OAuth, OpenID Connect, UMAなど)

PDSを実現するにあたっての技術動向の紹介 (OAuth, OpenID Connect, UMAなど) 2012年9月11日工藤達雄株式会社野村総合研究所 IT基盤インテグレーション事業本部 DIソリューション事業部

Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved.
OpenIDとOAuth ID 情報（認証結果と属性情報）を安全にサービス間でやりとりするための API 仕様 あるサービスの API アクセスの許可を、別のサービスに安全に与えるための方法 1 OAuth （オーオース） OpenID （オープンアイディー）

OpenID 2

「OpenID 2.0」 ふたつのWebサイト間における、Webブラウザを用いたアイデンティティ情報（エンドユーザの認証結果と属性情報）の要求・提供を行うためのプロトコル 2007年12月に策定 仕様群 OpenID Authentication 2.0: 認証結果の要求・取得 拡張仕様 ▪ Attribute Exchange (AX) Extension 1.0: 属性情報の要求・取得 ▪ Provider Authentication Policy Extension (PAPE) 1.0: 認証ポリシーの公告・要求・表明 ▪ OpenID OAuth Extension (Draft): OpenID Authenticationの認証結果と同時に OAuth 1.0 トークンを要求・取得 ▪ OpenID User Interface Extension 1.0 （Draft): ユーザー認証・同意ページのユーザー・インタフェースの指定 3

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

OP と RP 間のやりとりの仕組み 5 ユーザエージェント（ブラウザ） RP OP エンドユーザーの ID/パスワード OpenID入力 ①ディスカバリ OpenID（URL）にアクセス OP の通信先（EndPoint URL）等を返却 ②アソシエーション共有秘密鍵の交換 ③認証要求リダイレクトによる OP への認証要求（ユーザと OP 間の認証処理と ID 情報提供への同意） ④認証応答リダイレクトによる ID 情報返却サービス提供 GET https://www.google.com/accounts/o8/ ud &openid.ns=http://specs.openid.net/a uth/2.0 ↑プロトコルバージョン &openid.assoc_handle=AMlY****A9 ↑②で交換した共有秘密鍵への参照キー &openid.mode=checkid_setup ↑モード（認証要求） &・・・・ GET https://iknow.jp/open_ids &openid.ns=http://specs.openid.net/a uth/2.0 &openid.assoc_handle=AMlY****A9 &openid.mode=id_res ↑モード（認証応答） &openid.claimed_id=https://www.goo gle.com/accounts/o8/id?id=AItO****aw m ↑OP が認証した識別子（OpenID） &openid.sig=5aDmb****ExYmdwqaU ↑パラメータの共有秘密鍵による署名要求リクエストのプロトコルバージョンを付与秘密鍵への参照キーによる、メッセージの改ざん対策 OP で認証された OpenID の返却改ざん検知用のメッセージ署名

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

OAuth 7

これまでの API アクセス制御 API アクセス制御とは? 認証: サービス（API）にアクセスしてきたユーザを特定する 認可: そのユーザが要求する機能やデータを提供してもよいかどうかコントロールする 従来の API アクセス管理のパターン IP アドレスによる認証・認可 ▪ API クライアントの IP アドレスを事前に登録し、API アクセスを管理 「API キー」による認証・認可 ▪ API クライアントに「API キー」（API リクエストに付加する符号）を配布し、API アクセスを管理 問題点 いずれの方式も、クライアント単位でのアクセス管理であり、ユーザー単位ではない ユーザーの ID/パスワードをクライアントが預かる場合には、さらに別の課題が生ずる ▪ クライアントが増える度に ID/パスワードの保管場所が増すことになり、セキュリティ・リスクが上昇 ▪ API クライアントがエンドユーザーのすべてのアクセス権限を持つことになり、アクセス権乱用・誤用のリスクが上昇 →この問題は OpenID では解決できない 8 エンドユーザー API クライアント API プロバイダ APIプロバイダのID/ パスワードを入力 APIプロバイダのID/ パスワードをリクエストに付加し、 APIを呼び出しエンドユーザーの ID/パスワード ID/パスワードを検証し、リクエストを受け付け、処理結果を返却サービスを提供サービスにアクセス「APIプロバイダーの ID/パスワードを入力してください」 ID/パスワードが外部のサービスに流出してしまうエンドユーザーの ID/パスワードを用いて何でもリクエストできてしまう

OAuth の登場 「トークンによる API アクセス制御」のフレームワーク トークン: ユーザーに成り代わってアクセスすることを示す符号 広く使われているのは「API プロバイダーがエンドユーザを直接認証するフロー」 APIクライアントが介在しないため、そこからの「ID/パスワードの流出」がなくなる ▪ API クライアントが管理するのはID/パスワードではなくトークン API 提供側はユーザー単位でのアクセス管理が可能 ▪ トークンはエンドユーザとひもづいている まもなくOAuth 2.0がRFC標準となる見込み 現行のOAuth 1.0はobsoleteに 9 エンドユーザー API クライアント API プロバイダエンドユーザーの ID/パスワード APIプロバイダのID/ パスワードを入力トークンをリクエストに付加し、 APIを呼出／応答サービスを提供サービスにアクセス APIプロバイダーに「特定のサービスにアクセスするためのトークン」を要求「APIプロバイダーの ID/パスワードを入力してください」トークンを APIクライアントに返却アクセス範囲を限定したトークンを要求することができる ID/パスワードが APIクライアントに漏えいしない

OAuth におけるサービス間のやりとりの仕組み 10 エンドユーザー API クライアント API プロバイダエンドユーザーの ID/パスワードトークンによる API呼出／応答サービスを提供サービスにアクセス認証・同意認可要求 APIプロバイダーに「特定のサービスにアクセスするためのトークン」を要求認可応答トークンをAPIクライアントに返却 GET https://www.facebook.com/dialog/o auth &client_id=*23***43 ↑予め払い出されたAPIクライアントID &response_type=token signed_request ↑認可応答形式 &scope=publish_stream manage_pages user_birthday ↑APIに対する参照権限範囲 &・・・ GET https://s- static.ak.fbcdn.net/connect/xd_prox y.php &signed_request=d6wfBx*****ei9 &access_token=AAA****UGOQc ↑アクセストークン &expires_in=4629 ↑アクセストークンの有効期限 &・・・プロプライエタリに交換されたクライアント識別用 ID API に要求する参照権限範囲（スコープ）の指定認可の結果提供されたトークン

OpenIDとOAuthの組み合わせ OpenID は意外と実装が難しい 鍵交換や署名の付与・検証を自力で実装することは比較的難易度が高い これらの処理を行うライブラリは多数あるが、環境によっては組み込みが難しい OAuth は単純には認証に使えない トークンはAPIアクセスのためであり、認証結果としては利用できない API の権限設定が粗いと、トークンが必要以上の権限を持つ 悪意のあるユーザ、サイトによって、権限の乱用や他人に成り済ましたトークン利用が可能となる OpenID と OAuth を組み合わせる仕様 (OpenID/OAuth Hybrid) も考案されているが… 仕様がドラフトのままアップデートされていない ▪ OAuth は1.0プロトコルベース 両プロトコルをそれぞれ実装する手間がかかる 11

OpenID Connect 12

OpenID Connectとは http://openid.net/connect OpenIDの次期バージョン OAuth 2.0 仕様をベースに拡張 「シンプルな認証結果と属性情報の取得」 (後述) の範囲であれば、一般的なOAuth 2.0認可 + API アクセスのフローとほぼ同様 メッセージ形式にJSONを採用 加えてJWT (JSON Web Token) を活用することにより、署名と暗号化をサポート 仕様のモジュラー化 かんたんなことをシンプルにする一方、複雑なことも実現可能に 13

OpenID Connectの系図 14 Source: http://civics.com/openid-connect-webinar/

OpenID 2.0 15 OpenIDプロバイダ（OP） RPのリクエストに基づきユーザー認証を行いその認証結果と属性情報を提供 OpenIDリライング・パーティ（RP） OPに認証結果や属性情報をリクエストしその情報をもとにユーザーにサービスを提供ユーザー RPへのアクセスを試みる過程においてOPから RPへの認証結果と属性情報の提供を許可 PCのWebブラウザ 1. 「OPの IDでログイン」 2. OPの場所を特定し、リクエスト/ レスポンスに用いる署名鍵を交換 4. ユーザー認証の実施と認証結果と属性情報の提供可否の確認 6. アクセスを許可しサービスを提供 3. 認証リクエスト（ブラウザをリダイレクト） 5. 認証レスポンス（ブラウザをリダイレクト）

OpenIDプロバイダ（OP） RPのリクエストに基づきユーザー認証を行いその認証結果と属性情報を提供 Web API （ID情報、ｌセッション管理、ソーシャル、決済、アクティビティ、…） OpenID 2.0の課題 (≒ OpenID Connectの注力分野) 16 OpenIDリライング・パーティ（RP） OPに認証結果や属性情報をリクエストしその情報をもとにユーザーにサービスを提供ユーザー RPへのアクセスを試みる過程においてOPから RPへの認証結果と属性情報の提供を許可 PCのWebブラウザ 1. 「OPの IDでログイン」 2. OPの場所を特定し、リクエスト/ レスポンスに用いる署名鍵を交換 3. 認証リクエスト（ブラウザをリダイレクト） 4. ユーザー認証の実施と認証結果と属性情報の提供可否の確認 5. 認証レスポンス（ブラウザをリダイレクト） 6. アクセスを許可しサービスを提供「携帯電話のWebブラウザや、 Webブラウザ以外のユーザー・エージェント（ネイティブ・アプリケーションや JavaScriptクライアントなど）にも対応したい」「認証リクエスト/ レスポンスに対して、公開鍵を用いて暗号化・署名したい」「OP/RP間の設定をもっとかんたんに、もしくは省略したい」「OPの提供する他のAPIとかんたんに組み合わせたい」

OpenID Connectの特徴 17 エンドユーザー API クライアント API プロバイダーエンドユーザーの ID/パスワードアクセストークンによる API呼出／応答サービスを提供サービスにアクセス認証・同意認可要求 APIプロバイダーに「特定のサービスにアクセスするためのトークン」を要求認可応答認可コードをAPIクライアントに返却アクセストークン要求・応答 UserInfo要求・応答 OAuth の認証では不十分だった、認証コンテキスト（いつ、誰が、誰を認証したのか等）を「ID トークン」として提供属性提供を行う UserInfoAPI が規定され、API アクセスの標準ルールが策定（認可コードとアクセストークンを引換え/IDトークンの返却） OAuth2.0 ベースによる、トークンを利用した全体的なフロー・OAuth2.0 に対応済みであれば、一部の拡張で OpenID Connect に対応可能

OpenID Connectのフロー（概要） 18 認可サーバーユーザー情報（クレーム） 3. ユーザー認証・認可クライアント 5. ユーザー属性提供要求クレームプロバイダクレームソース UserInfo エンドポイントエンドユーザー認可エンドポイント 1. サービスにアクセス OpenID プロバイダ 3 1 2 4 2. トークン取得要求（ブラウザのリダイレクト） 4. アクセス・トークンとID トークンを返却（ブラウザのリダイレクト） 5 6 6 . ユーザー属性提供 7.（オプション）: ユーザー属性提供要求 7 8 8. （オプション）: ユーザー属性提供 9 . サービス提供 9

OpenID Connect Protocol Suite 「公式マップ」 http://openid.net/connect …が、以下のほうが実態に近い気がする 19 Bindings •Basic Client Profile •Implicit Client Profile •Standard •Other Vendor Proprietary / Community Specific Bindings Endpoints and associated message formats •Messages Optional Functionality •Discovery •Dynamic Client Registration •Session Management •Other Vendor Proprietary / Community Specific Functionality Underpinnings

OpenID Connect のユースケース 1. シンプルな認証結果と属性情報の取得 OpenID Connectフローの処理の結果、クライアントは認可サーバーから id_tokenとアクセス・トークンを得る 認証結果: id_tokenから抽出 id_token ▪ JWT(JSON Web Token)形式 ▪ JWS (JSON Web Signature)により署名 ▪ 発行者（iss）、エンドユーザーの識別子（user_id）、トークンのオーディエンス（aud)、有効期間（exp)、発行時間（iat）などが含まれている 検証方法 ▪ 取得したクライアント自身がid_tokenを検証 属性情報: アクセス・トークンを用いて取得 クライアントはフロー開始時（認可リクエスト）のscopeに、取得したい「クレーム」を指定 ▪ 指定可能なクレームはprofile (一般的なユーザー属性(address, emailを除く)), address (住所), email (メールアドレス) 、phoneの4種類（複数同時に指定可能） 取得したアクセス・トークンを用いてUserInfoエンドポイントにアクセスし、属性を取得 ▪ JSON形式 20

OpenID Connect のユースケース 2. 仕様に規定されている以外の属性の取得 認可リクエストのscopeに独自の「クレーム」を指定 さらに認可リクエストに「リクエスト・オブジェクト」を付加し、要求する属性を指定 リクエスト・オブジェクト 認可サーバーへのリクエスト・パラメータをJWT化したもの 認可リクエストへの付加方法 ▪ requestパラメータの値としてリクエスト・オブジェクトを指定 ▪ request_uriパラメータの値として、リクエスト・オブジェクトの場所を指定 例: もし「edupersonクレーム」を作る場合 scopeにedupersonを指定 リクエスト・オブジェクトとして以下の内容を指定 UserInfoにアクセスすることにより、以下の属性を取得 21 { "user_id": null, "urn:mace:dir:attribute-def:cn" : {"optional": true}, "urn:mace:dir:attribute-def:sn" : {"optional": true}, "urn:mace:dir:attribute-def:givenName" : {"optional": true}, "urn:mace:dir:attribute-def:mail" : null } { "user_id": "248289761001", "urn:mace:dir:attribute-def:cn" : "John Bradley", "urn:mace:dir:attribute-def:sn" : "Bradley", "urn:mace:dir:attribute-def:givenName" : "John", "urn:mace:dir:attribute-def:mail" "[email protected]" }

OpenID Connect のユースケース 3. ユーザー認証の保証レベルの指定 認可リクエストに付加する「リクエスト・オブジェクト」に、要求する保証レベルを指定  ユーザー認証後得られた id_tokenに、保証レベルが含まれる 例 リクエスト・オブジェクトとして以下の内容を指定 ユーザー認証後取得した id_tokenに以下の内容が含まれる 22 "id_token": { "claims": { "auth_time": null, “acr": { "values":["2"] } }, "max_age": 86400, } “acr": {"values":["3","2"]}

OpenID Connect のユースケース 4. UserInfoエンドポイントの外部にあるクレームの取得 UserInfoから提供する外部のクレームとして、「集約（aggregated）クレーム」と「分散（distributed）クレーム」を規定 集約（aggregated）クレーム UserInfoエンドポイントから提供されるクレームの中に、外部クレームの「実体」が含まれる ▪ その「実体」はJWT形式に変換して含まれることにより、他のクレームと区別される 分散（distributed）クレーム UserInfoエンドポイントから提供されるクレームの中に、外部クレームを取得するための情報が含まれる ▪ 場合によっては、取得するための情報としてアクセス・トークンが指定されている 23

OpenID Connect のユースケース 5. クライアントによるOpenIDプロバイダのディスカバリ OpenID Connect Discovery エンドユーザーが指定した識別子をもとに、OpenIDリライング・パーティがOpenIDプロバイダを発見する仕組みを定義 ▪ OpenID 2.0にて実現されていた機能と同様 識別子は以下のどちらかであるべきである (SHOULD) ▪ メールアドレス or URL 識別子を元にOpenIDリライング・パーティは、SWD (Simple Web Discovery) により、OpenIDプロバイダを発見する 24 GET /.well-known/simple-web-discovery?principal=joe%40example.com&service=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1.1 Host: example.com HTTP/1.1 200 OK Content-Type: application/json { "locations":["https://server.example.com"] }

OpenID Connect のユースケース 6. クライアント情報の動的な登録 OpenID Connect Dynamic Client Registration OpenIDプロバイダとOpenIDリライング・パーティとが、動的に信頼関係を確立する仕組みを定義 ▪ OpenID 2.0にて実現されていた機能と同様 OpenIDリライング・パーティがOpenIDプロバイダの「クライアント登録エンドポイント」に、自身を登録するようリクエスト ▪ 成功した場合、レスポンスとしてclient_id/client_secretが返却される 25 POST /connect/register HTTP/1.1 Accept: application/x-www-form-urlencoded Host: server.example.com Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ ... fQ.8Gj_-sj ... _X type=client_associate &redirect_uris=https://client.example.org/callback %20https://client.examp le.org/callback2 &logo_url=https://client.example.org/logo.png &user_id_type=pairwise &sector_identifier_url= https://othercompany.com/file_of_redirect_uris_for_our_sites.js &token_endpoint_auth_type=client_secret_basic &jwk_url=https://client.example.org/my_rsa_public_key.jwk &userinfo_encrypted_response_alg=RSA1_5 &userinfo_encrypted_response_enc=A128CBC &userinfo_encrypted_response_int=HS256 HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "client_id":"s6BhdRkqt3", "client_secret": "cf136dc3c1fd9153029bb9c6cc9ecead918bad9887fce6c93f31185e58858 05d", "expires_at":2893276800 }

OpenID Connect のユースケース 7. セッション管理 OpenID Connect Session Management OpenIDプロバイダ（認可サーバー）におけるユーザーのログイン/ログアウトの状況を、OpenIDリライング・パーティ（サードパーティ）が継続的にモニターする仕組みを定義 OP/RPの通信にiframeを利用 26

OpenID Connectの今後のロードマップ 現在Implementer’s Draftが公開中 今後最終仕様に OpenID Connectをサポートする製品・サービスベンダー（予定含む） Gluu、IBM、Layer7、Microsoft、野村総合研究所、Ping Identity、 Vordel、… AOL、Google、日本経済新聞社、PayPal、楽天、Salesforce.com、 Yahoo! JAPAN、… 27

UMA (User Managed Access) 28

User Managed Access (UMA) http://kantarainitiative.org/confluence/display/uma/Home データ共有とサービス・アクセスに関する認可をユーザがコントロールできるようにするためのWebプロトコル カンターラ・イニシアチブのワーク・グループとして活動 現在、仕様のドラフトを策定中 IETFにて標準化を予定 OAuth 2.0 ベース 29

リソースごとに行われている認可管理 30

Host / Protected Resource UMA: Authorization Managerに認可管理を集約 31 Authorization Manager Requester / Requesting Party ユーザが利用しているホスト/リソースを、同じく利用している管理サービスに登録リソースへのアクセスを許可 Authorizing Party 利用者の同意に基づくリソースの活用

OAuth 2.0とUMAの比較 UMAプロトコルはOAuth 2.0をベースに以下を拡張 だれにデータを共有するか（クライアント上の自分 vs. 任意の誰か） リソースと認可サービスとの関係（サービスが規定 vs. ユーザが指定） 発行するトークンをどのように決定するか（ユーザ認証結果に基づく vs. ユーザのポリシーとリクエスタのクレームに基づく） データの提供者と利用者との関係（事前登録 vs. 動的登録） Source: http://kantarainitiative.org/confluence/download/attachments/37751312/IIW10-UMA-May2010.pdf OAuth 2.0 UMA

UMAの登場人物 Authorization Managerにおいてポリシーを設定する。ポリシーによって、Host上の Protected ResourceにRequesterがアクセスを試みたときにどうするかが決定される Authorizing Userのポリシーを適用し、Protected Resourceへのアクセスを統制する (policy decision) リクエストを行う主体はAuthorizing User本人、またはユーザ個人や企業・団体。これらRequesting Partyが、 Requesterを用いて、Protected Resourceへのアクセスを試みる Hostは自身の管理する Protected Resourceへのアクセスを、Authoriziation Managerの決定に従い管理する (policy enforcement) Source: http://kantarainitiative.org/pipermail/wg-uma/2012-August/001956.html 33

UMAのユースケース例 Person-to-self sharing Authorizing PartyとRequesting Partyが同一の人物であるケース Person-to-person sharing Authorizing Partyが別の人物であるRequesting Partyにアクセス認可を与えるケース Mediated person-to-organization sharing Authorizing Partyが別の組織に属する人物であるRequesting Partyにアクセス認可を与えるケース Autonomous person-to-organization sharing Authorizing Partyが公開した「パーソナルRFP（提案依頼）」に対し、別の組織がRequesting Partyとなって提案するようなケース ▪ Requesting Party側では、人が介在しない 34 Source: Binding Obligations on User-Managed Access (UMA) Participants 1.1. Sample Use Cases for Sharing Access to Resources http://docs.kantarainitiative.org/uma/draft-uma-trust.html#anchor1

Authorizing User （ブラウザもしくは他のユーザ・エージェントを利用するユーザ） Step 1: UserがAMにHostを紹介 1a: UserがAMの場所を指示 2a: Userが Resourceのありかを提示 1d: ポリシーを定義 Step 2: Requesterがアクセス・トークンを取得 2c: アクセス・トークンを要求。場合によりクレームを提示 2b: アクセス試行 1b: メタデータ取得 1c: HostがAMを信頼することを認可 3b: トークンの検証（オプション） Step 3: Requesterが Resourceにアクセス Source: http://kantarainitiative.org/confluence/download/attachments/37751312/IIW10-UMA-May2010.pdf UMAのステップ 35

UMAを採用している/採用を検討しているサービス 36 Source: UMA Implementations - WG - User Managed Access - Kantara Initiative http://kantarainitiative.org/confluence/display/uma/UMA+Implementations

PDSを実現するにあたっての技術動向の紹介 (OAuth, OpenID Connect, U...

PDSを実現するにあたっての技術動向の紹介 (OAuth, OpenID Connect, UMAなど)

More Decks by Tatsuo Kudo

Other Decks in Technology

Featured

Transcript