利用者本位のAPI提供に向けたアイデンティティ (ID) 標準仕様の動向

FinTech協会 APIセキュリティ分科会
利用者本位のAPI提供に向けたアイデンティティ（ID）標準仕様の動向
OAuth / OpenID Connect / FIDO
2016年9月28日
NRIセキュアテクノロジーズ株式会社
コンサルティング事業本部
サイバーコンサルティング部
工藤達雄
〒100-0004
東京都千代田区大手町1-7-2 東京サンケイビル

Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 1
工藤達雄 http://www.linkedin.com/in/tatsuokudo/ @tkudos
サン・マイクロシステムズ (1998~2008)
野村総合研究所 (2008~)
OpenIDファウンデーション・ジャパン (2013~2014)
NRIセキュアテクノロジーズ (2014~)
▪ 現在はデジタル・アイデンティティとAPIを専門とする
コンサルティングに従事
自己紹介

「認証技術」と「デジタルアイデンティティ技術」

ユーザー認証
エンドユーザー
APP
サービス
サービス提供
アクセス試行
ユーザー認証

アイデンティティ連携
APP
サービスユーザー認証
サードパーティ
Webサイト
アクセス試行
認証依頼認証結果提供

API
サーバー
APIアクセス認可
APP
APIクライアント
（Webサイトなど）
サービス
アクセス試行
APIアクセス
許可要求
APIアクセス
許可
APIアクセス
Webサイト
ユーザー認証

API
サーバー
アイデンティティ・プロビジョニング
APP
サービス
Webサイト
エンドユーザー /
管理者
ユーザー情報
追加・変更・削除
ユーザー情報
同期

API
サーバー
オープン標準 “FIDO” “SAML” “OpenID Connect” “OAuth” “SCIM”
APP
サービス
アクセス試行
サービス提供
ユーザー認証
アクセス試行
APIアクセス
許可要求
APIアクセス
許可
APIアクセス
Webサイト
アクセス試行
エンドユーザー /
管理者
ユーザー情報
追加・変更・削除
ユーザー情報
同期

B2Cサービスにおけるアイデンティティ技術仕様として広まりつつある “FIDO” “OAuth” “OpenID Connect”
各種API
APP
“共通ID基盤”
アクセス試行
サービス提供
ハードウェアを用いた二要素認証
アクセス試行各種APIへの
アクセス許可要求
APIアクセス
Webサイト
アクセス試行
APIプロバイダーのIDでログイン
APIプロバイダー

OAuth

OAuth登場の背景
ダイレクトチャネルはID/パスワードでログイン
コンテンツ/
機能
Webサイト
モバイルAPI
サービス事業者
ID/パスワード
ID/パスワード
APP

サードパーティにAPIを公開する場合はどうするか
コンテンツ/
機能
Webサイト
モバイルAPIID/パスワード
ID/パスワード
外部向け
API
Webサイト
モバイルAPI
APP
APP
APP
ID/パスワード…!?

ユーザーはID/パスワードをサードパーティに
預けることになる → 認証リスク
サードパーティからの情報漏えいやサードパーティ自身
による不正利用の懸念が残る
ユーザーはサードパーティに全権委任する
ことになる → 認可リスク
サードパーティは本来サービスに不要な（過剰な）
APIアクセスを行うこともできてしまう
使い勝手が悪い
サードパーティのアクセス有効期間を制御できない
サードパーティにユーザーのID/パスワードを渡す?
“When customers give out
their bank passcode, they
may not realize that if a
rogue employee at an
aggregator uses this
passcode to steal money
from the customer’s
account, the customer, not
the bank, is responsible for
any loss.”
--- Jamie Dimon's Letter to Shareholders,
Annual Report 2015 | JPMorgan Chase & Co.
http://www.jpmorganchase.com/corporate/annual
-report/2015/

ID/パスワードではなく「トークン」を渡す
コンテンツ/
機能
Webサイト
モバイルAPIID/パスワード
ID/パスワード
外部向け
API
APP
トークン
管理
ID/パスワード +
権限委譲
トークン
発行
トークン

「アクセストークン」によるAPIアクセス認可のフレームワーク
APIアクセス認可: OAuth
リソースオーナー
リソース
サーバー
APP
認可
サーバー
クライアント
HTML5
WEBSITE
0
0. リソースへのアクセスを
リクエスト
1
1. 認可
リクエスト
2
2. ユーザー認証 &
クライアントへの権限委譲の確認
3
3. OK!
4 4. アクセストークン
提供
5
5. アクセストークンを
使ってAPIアクセス

英国 “The Open Banking
Standard” が、今後策定予定の
“The Open Banking API” では
OAuth 2.0 （と OpenID
Connect）を採用するよう
推奨している
“A core principle of this
report is informed consent”
誰を認可するか、なにを認可
するか、いつまで認可を有効
にするかが重要
金融サービス分野におけるアイデンティティ技術の活用
Source: The Open Banking Standard https://www.scribd.com/doc/298569302/The-Open-Banking-Standard
OAuth 2.0 in conjunction with OpenID Connect
are recommended as authentication protocols of
choice

国内外の金融機関が、すでにOAuth 2.0を活用した「金融API」の提供を
始めている
金融サービス分野におけるアイデンティティ技術の活用 (cont.)
Source: Fidor API Reference http://docs.fidor.de/#understand-oauth,
Documentation – APImarket https://www.bbvaapimarket.com/web/api_market/bbva/bbva-connect/documentation

APIへのOAuth適用のポイント
関連仕様やセキュリティのプラクティスを活用し、認可フロー、トークン管理、スコープ体系などをAPI/サービスに
最適化する「プロファイリング」が必要
OAuth (OAuth 2.0)は「プロトコル」ではなく「フレームワーク」である
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI ---->| |
| User- | | Authorization |
| Agent -+----(B)-- User authenticates --->| Server |
| | | |
| -+----(C)-- Authorization Code ---<| |
+-|----|---+ +---------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+---------+ | |
| |>---(D)-- Authorization Code ---------' |
| Client | & Redirection URI |
| | |
| |<---(E)----- Access Token -------------------'
+---------+ (w/ Optional Refresh Token)
認可フローにおけるセキュリティの懸念の例
（https://tools.ietf.org/html/rfc6749 の図に加筆）
(A) “Web View” からの認可リクエスト（モバイルの
場合）、不正なredirect_uri、…
(C) ユーザーエージェ
ントすり替わり、
CSRF、リファラーか
らの認可コード漏洩、
オープンリダイレクタ
の悪用、他社認可サー
バーの不備・不正によ
る “Mix-Up Attack”、
…
(D) クライアントすり替わり、認可
コード再利用・すり替え、…
Slackのスコープ定義の例 Source: https://api.slack.com/docs/oauth-scopes
Microsoft Azure ADのトークン有効期限の例
Source: https://azure.microsoft.com/ja-jp/documentation/articles/active-directory-v2-tokens/

OpenID Connect

API
サーバー
OAuthはID連携にも使える?
OAuth仕様が標準化する対象は「アクセストークン」のやりとりであり、「認証依頼」と「認証結果提供」のやりとり、
そして「認証結果」（ID情報）の定義は書かれていない
APP
サービス
アクセス試行
APIアクセス
許可要求
APIアクセス
許可
APIアクセス
Webサイト
ユーザー認証
アクセス試行
アイデンティティ連携
サードパーティに「いまアクセス
してきたユーザーに関する情報」
を提供する
APIアクセス認可
(OAuth)
サードパーティに「ユーザーに
成り代わってアクセスをする
ための許可証」を提供する
扱う情報が異なる

API
サーバー
OAuthはID連携にも使える?
OAuth 2.0仕様をベースに「アイデンティティ層」を拡張し、認証結果や属性情報の連携、
セッション管理などのAPIを標準化
アイデンティティ連携: OpenID Connect (OIDC)
APP
サービス
アクセス試行
APIアクセス許可要求
+ 認証依頼
APIアクセス許可
+ 認証結果提供
APIアクセス
ユーザー認証
認証結果（IDトークン）
• ID情報提供側におけるユーザ
認証イベントの情報
• エンドユーザーを識別する値
（識別子）
• IDトークンの有効期限
• ユーザ認証を実施した日時
• 認証コンテクスト・クラス・
リファレンス
• 認証手段リファレンス
• その他（ユーザー属性など）
• 署名付きJWT（Signed JSON
Web Token）として表現

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

FIDO

「ローカル認証」と「オンライン認証」を分離
ユーザー検証はローカルに行い、ユーザー検証結果のみがオンラインに流れる
FIDO認定試験を定期的に開催し、製品・サービスの相互運用性を強化
ユーザー認証: FIDO
Source: “FIDO技術のさらなる広がり” https://fidoalliance.org/wp-content/uploads/FIDOTokyoSeminar-gomi-112015-ja.pdf

FIDO認定製品が急速に増加
2016年6月に約200 → 同年9月に250超
FIDO (Cont.)
Source: “FIDO Certification” http://www.slideshare.net/FIDOAlliance/fido-certification

まとめ

アイデンティティ技術を活用した「利用者本位のAPI提供」に向けて
API
サーバー
APP
サービス
アクセス試行
サービス提供
ユーザー認証
アクセス試行
APIアクセス
許可要求
APIアクセス
許可
APIアクセス
Webサイト
アクセス試行
FIDO: 利用者が使いやすく
確実な認証手段を
活用できるようになる
OAuth: 利用者が自身
の情報の第三者利用を
コントロールしやすく
なる
OpenID Connect:
利用者が自身のIDを
他事業者の
サービスでも
使えるようになる

Tatsuo Kudo
tkudo@nri-secure.co.jp
https://www.linkedin.com/in/tatsuokudo
@tkudos

利用者本位のAPI提供に向けたアイデンティティ (ID) 標準仕様の動向

More Related Content

What's hot

Viewers also liked

Similar to 利用者本位のAPI提供に向けたアイデンティティ (ID) 標準仕様の動向

More from Tatsuo Kudo

利用者本位のAPI提供に向けたアイデンティティ (ID) 標準仕様の動向