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

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

2012年9月11日

工藤達雄
株式会社野村総合研究所
IT基盤インテグレーション事業本部
DIソリューション事業部

OpenIDとOAuth

ID 情報（認証結果と属性情 あるサービスの API アクセ
報）を安全にサービス間でやスの許可を、別のサービス
りとりするための API 仕様に安全に与えるための方法

OpenID OAuth
（オープンアイディー）（オーオース）
Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 1

「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): ユーザー認証・同意ページのユー
ザー・インタフェースの指定

OpenID の概念と登場人物
ユーザがアイデンティティ (ID) 情報の提供サイトを選択（ただし実際にはホワ
イトリストによる運用が一般的）
OpenID プロバイダ (OP): ID 情報 (認証結果や属性情報) を RP に提供するサイト
OpenID リライング・パーティ (RP): OP から提供された ID 情報を受け入れるサイト

RP：ID情報の受入側
OP：ID情報の提供側 RP (無料日記
OP(ポータルサービス)
サイト) 「誰でも気軽にコメ
誰でも即時アカ ID / パスワード
ID情報の提供
ントしてほしい」
ウント取得可能でログイン

OP(航空券 RP(ホテル予約
予約サービス) ID / 画像認証 ID情報の提供サービス)
クレジットカードでログイン「確かな属性情報が
ほしい」
番号等を管理
ID情報の提供
OP(高度認証 ICカードの証
明書でログイン
クレデンシャル情報（ID/PW等）の入力 RP (医療情報
サービス)
登録時に厳密な
によるユーザの特定はOP側で行うため、管理サービス)
本人確認を行ない、 RP側にクレデンシャル情報を流通させ「本人以外には決し
多要素認証を実施る必要がないて公開しない」


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

OpenID 2.0の普及動向

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

これまでの API アクセス制御
API アクセス制御とは? エンド API API
 認証: サービス（API）にアクセスしてきたユーザを特定するユーザークライアントプロバイダ

 認可: そのユーザが要求する機能やデータを提供してもエンドユーザーの

よいかどうかコントロールする
ID/パスワード

従来の API アクセス管理のパターンサービスにアクセス

 IP アドレスによる認証・認可 ID/パスワードが
▪ API クライアントの IP アドレスを事前に登録し、API アクセスを管理「APIプロバイダーの
外部のサービスに
流出してしまう
 「API キー」による認証・認可 ID/パスワードを入力
してください」

▪ API クライアントに「API キー」（API リクエストに付加する符号）を配 APIプロバイダのID/
布し、API アクセスを管理パスワードを入力

問題点
 いずれの方式も、クライアント単位でのアクセス管理であり、 APIプロバイダのID/
ユーザー単位ではないエンドユーザーのパスワードを
リクエストに付加し、
ID/パスワードを APIを呼び出し
 ユーザーの ID/パスワードをクライアントが預かる場合には、用いて何でも
さらに別の課題が生ずるリクエストできて ID/パスワードを検証し、
▪ クライアントが増える度に ID/パスワードの保管場所が増すことになしまうリクエストを受け付け、
処理結果を返却
り、セキュリティ・リスクが上昇
▪ API クライアントがエンドユーザーのすべてのアクセス権限を持つことサービスを提供
になり、アクセス権乱用・誤用のリスクが上昇
 →この問題は OpenID では解決できない

OAuth の登場
「トークンによる API アクセス制御」のフエンド API API
レームワークユーザークライアントプロバイダ

トークン: ユーザーに成り代わってアクセスすエンドユーザーの
ID/パスワード

ることを示す符号
サービスにアクセスアクセス範囲を限
広く使われているのは「API プロバイダー APIプロバイダーに「特定の
定したトークンを要
がエンドユーザを直接認証するフロー」サービスにアクセスするための
トークン」を要求
求することができる

APIクライアントが介在しないため、そこからの
「ID/パスワードの流出」がなくなる ID/パスワードが
▪ API クライアントが管理するのはID/パスワードで APIクライアントに
「APIプロバイダーの漏えいしない
はなくトークン ID/パスワードを入力
してください」
API 提供側はユーザー単位でのアクセス管理 APIプロバイダのID/

が可能パスワードを入力

▪ トークンはエンドユーザとひもづいているトークンを
APIクライアントに返却

まもなくOAuth 2.0がRFC標準となる見
込みトークンを
リクエストに付加し、
APIを呼出／応答
現行のOAuth 1.0はobsoleteにサービスを提供


OAuth におけるサービス間のやりとりの仕組み
GET
エンド API API
https://www.facebook.com/dialog/o
プロプライエタリに
ユーザークライアントプロバイダ
auth 交換されたクライア
エンドユーザーの
ID/パスワード &client_id=*23***43 ント識別用 ID
サービスにアクセス ↑予め払い出されたAPIクライアントID
&response_type=token
signed_request
認可要求
↑認可応答形式 API に要求する参
APIプロバイダーに「特定のサービスに
アクセスするためのトークン」を要求 &scope=publish_stream 照権限範囲（スコー
manage_pages user_birthday
↑APIに対する参照権限範囲
プ）の指定
認証・同意 &・・・

認可応答 GET https://s- 認可の結果提供さ
static.ak.fbcdn.net/connect/xd_prox
トークンをAPIクライアントに返却れたトークン
y.php
&signed_request=d6wfBx*****ei9
&access_token=AAA****UGOQc
トークンによる ↑アクセストークン
API呼出／応答 &expires_in=4629
↑アクセストークンの有効期限
サービスを提供 &・・・


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

OpenID Connectとは
http://openid.net/connect

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


OpenID Connectの系図

Source: http://civics.com/openid-connect-webinar/


OpenID 2.0
OpenIDプロバイダ（OP） OpenIDリライング・パーティ（RP）
RPのリクエストに基づきユーザー認証を行い OPに認証結果や属性情報をリクエストし
その認証結果と属性情報を提供その情報をもとにユーザーにサービスを提供
2. OPの場所を特定し、リクエスト/
レスポンスに用いる署名鍵を交換

5. 認証レスポンス 3. 認証リクエスト
（ブラウザを（ブラウザを
リダイレクト）リダイレクト）

4. ユーザー認証の実施と
認証結果と属性情報の 1. 「OPの 6. アクセスを
提供可否の確認 IDで許可し
ログイン」サービスを
提供
PCのWebブラウザ

ユーザー
RPへのアクセスを試みる過程においてOPから
RPへの認証結果と属性情報の提供を許可

OpenID 2.0の課題 (≒ OpenID Connectの注力分野)
「OP/RP間の設定をもっとかんたんに、
OpenIDプロバイダ（OP）もしくは省略したい」 OpenIDリライング・パーティ（RP）
RPのリクエストに基づきユーザー認証を行い OPに認証結果や属性情報をリクエストし
その認証結果と属性情報を提供その情報をもとにユーザーにサービスを提供
2. OPの場所を特定し、リクエスト/
レスポンスに用いる署名鍵を交換

Web API
（ID情報、ｌセッション管理、「認証リクエスト/
ソーシャル、決済、レスポンスに対して、
アクティビティ、…）
公開鍵を用いて
暗号化・署名したい」
5. 認証レスポンス 3. 認証リクエスト
「OPの提供する（ブラウザを（ブラウザを
他のAPIとリダイレクト）リダイレクト）
かんたんに
組み合わせたい」 4. ユーザー認証の実施と
1. 「OPの 6. アクセスを
認証結果と属性情報の
提供可否の確認 IDで許可し
ログイン」サービスを
提供
PCのWebブラウザ

「携帯電話のWebブラウザや、
Webブラウザ以外の
ユーザー・エージェント
（ネイティブ・アプリケーションや
JavaScriptクライアントなど）
ユーザー
にも対応したい」
RPへのアクセスを試みる過程においてOPから
RPへの認証結果と属性情報の提供を許可

OpenID Connectの特徴
エンド API API
ユーザークライアントプロバイダー

エンドユーザーの
OAuth2.0 ベースによる、トークンを利用
ID/パスワード
した全体的なフロー
サービスにアクセス・OAuth2.0 に対応済みであれば、一部
認可要求の拡張で OpenID Connect に対応可能
APIプロバイダーに「特定のサービスに
アクセスするためのトークン」を要求

認証・同意
OAuth の認証では不十分だった、認
証コンテキスト（いつ、誰が、誰を認証
認可応答
したのか等）を「ID トークン」として提供
認可コードをAPIクライアントに返却

アクセストークン要求・応答
（認可コードとアクセストークンを
引換え/IDトークンの返却）
属性提供を行う UserInfoAPI が規定さ
れ、API アクセスの標準ルールが策定
UserInfo要求・応答
アクセストークンによる
API呼出／応答

サービスを提供


OpenID Connectのフロー（概要）
7.（オプション）:
ユーザー属性
7 8. （オプショ
クレームクレーム
ソース
提供要求
ン）: ユーザー
プロバイダ 8 属性提供
5. ユーザー属性
提供要求
5 6 . ユーザー
属性提供
OpenID ユーザー UserInfo
6
クライアント
プロバイダ情報
エンドポイント

2. トークン 2
（クレーム）取得要求
（ブラウザの 4
リダイレクト） 4. アクセス・
トークンとID
エンドユーザートークンを返却
認可（ブラウザの
エンドポイント
リダイレクト）
認可
サーバー
1. サービスに 9 . サービス
アクセス提供
1 9

3

3. ユーザー
認証・認可


OpenID Connect Protocol Suite
「公式マップ」 …が、以下のほうが実態に近
http://openid.net/connect い気がする
Bindings
•Basic Client Profile
•Implicit Client Profile
•Standard
•Other Vendor Proprietary / Community Specific Bindings

Endpoints and Optional Functionality
•Discovery
associated message •Dynamic Client Registration
formats •Session Management
•Other Vendor Proprietary /
•Messages 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形式


2. 仕様に規定されている以外の属性の取得
認可リクエストのscopeに独自 例: もし「edupersonクレーム」
の「クレーム」を指定を作る場合
さらに認可リクエストに「リクエ scopeにedupersonを指定
スト・オブジェクト」を付加し、要 リクエスト・オブジェクトとして以下
求する属性を指定の内容を指定
{
リクエスト・オブジェクト "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
ラメータをJWT化したもの }

認可リクエストへの付加方法 UserInfoにアクセスすることによ
▪ requestパラメータの値としてリクエり、以下の属性を取得
スト・オブジェクトを指定 {
"user_id": "248289761001",
▪ request_uriパラメータの値として、 "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" "ve7jtb@ve7jtb.com"
}


3. ユーザー認証の保証レベルの指定

認可リクエストに付加する 例
「リクエスト・オブジェクト」に、 リクエスト・オブジェクトとして
要求する保証レベルを指定以下の内容を指定
"id_token":

 ユーザー認証後得られた {
"claims":
{

id_tokenに、保証レベルが "auth_time": null,
“acr": { "values":["2"] }
},
含まれる }
"max_age": 86400,

ユーザー認証後取得した
id_tokenに以下の内容が含ま
れる
“acr": {"values":["3","2"]}


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

5. クライアントによるOpenIDプロバイダのディスカバリ

OpenID Connect Discovery
エンドユーザーが指定した識別子をもとに、OpenIDリライング・パー
ティがOpenIDプロバイダを発見する仕組みを定義
▪ OpenID 2.0にて実現されていた機能と同様
識別子は以下のどちらかであるべきである (SHOULD)
▪ メールアドレス or URL
識別子を元にOpenIDリライング・パーティは、SWD (Simple Web
Discovery) により、OpenIDプロバイダを発見する
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"]
}


6. クライアント情報の動的な登録

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

7. セッション管理

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


OpenID Connectの今後のロードマップ

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


UMA (User Managed Access)

28

User Managed Access (UMA)
http://kantarainitiative.org/confluence/display/uma/Home

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


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


UMA: Authorization Managerに認可管理を集約
Host / Requester /
Authorization Manager
Protected Resource Requesting Party

リソースへの
アクセスを許可
ユーザが利用してい
るホスト/リソースを、
同じく利用している
管理サービスに登録

Authorizing Party

利用者の同意に基づく
リソースの活用

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

Source: http://kantarainitiative.org/confluence/download/attachments/37751312/IIW10-UMA-May2010.pdf
Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved.

Authorization Managerにおいてポリシー
UMAの登場人物を設定する。ポリシーによって、Host上の
Protected ResourceにRequesterがアクセ
スを試みたときにどうするかが決定される

Hostは自身の管理する
Protected Resourceへのア
クセスを、Authoriziation
Managerの決定に従い管理
する (policy enforcement) Authorizing Userのポリシーを適用
し、Protected Resourceへのアクセ
スを統制する (policy decision)

リクエストを行う主体はAuthorizing
User本人、またはユーザ個人や企
業・団体。これらRequesting Partyが、
Requesterを用いて、Protected
Resourceへのアクセスを試みる

Source: 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側では、人が介在しない
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

UMAのステップ
2c: アクセス・トークンを要求。場合によりクレームを提示

1b: メタデータ取得

2b: アクセス試行

3b: トークンの検証
（オプション） Step 3: Requesterが
Resourceにアクセス

1d: ポリシー 1a: UserがAMの 2a: Userが
を定義場所を指示 Resourceの
ありかを提示
1c: HostがAMを信頼することを認可

Step 1: UserがAMにHostを紹介

Step 2: Requesterがアクセス・トークンを取得

Authorizing User （ブラウザもしくは他のユーザ・エージェントを利用するユーザ）
Source: http://kantarainitiative.org/confluence/download/attachments/37751312/IIW10-UMA-May2010.pdf

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

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

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

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

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (13)

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

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

Mais de Tatsuo Kudo

Mais de Tatsuo Kudo (20)

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