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 プロバイダ


ID/パスワード

APIプロバイダのID/パスワードを入力

トークンをリクエストに付加し、 APIを呼出／応答



APIプロバイダーに「特定のサービスにアクセスするための

トークン」を要求

「APIプロバイダーのID/パスワードを入力してください」

トークンを APIクライアントに返却

アクセス範囲を限定したトークンを要求することができる

ID/パスワードが APIクライアントに漏えいしない


OAuth におけるサービス間のやりとりの仕組み

10



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/

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 プロバイダー


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]"

}

mailto:[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

http://kantarainitiative.org/pipermail/wg-uma/2012-August/001956.html






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

http://docs.kantarainitiative.org/uma/draft-uma-trust.html







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

http://kantarainitiative.org/confluence/download/attachments/37751312/IIW10-UMA-May2010.pdf







UMAを採用している/採用を検討しているサービス

36

Source: UMA Implementations - WG - User Managed Access - Kantara Initiative http://kantarainitiative.org/confluence/display/uma/UMA+Implementations

http://kantarainitiative.org/confluence/display/uma/UMA+Implementations

http://kantarainitiative.org/confluence/display/uma/UMA+Implementations

pdsを実現するにあたっての技術動向の紹介 (oauth, openid connect, umaなど)

Documents