利用者本位の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を専門とするコンサルティングに従事

自己紹介

http://www.linkedin.com/in/tatsuokudo/


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



ユーザー認証

エンドユーザー

APP

サービス

サービス提供

アクセス試行

ユーザー認証



アイデンティティ連携


APP

サービスユーザー認証

サードパーティ

Webサイト

アクセス試行

認証依頼認証結果提供


API

サーバー


APIアクセス認可


APP


APIクライアント

（Webサイトなど）

サービス

アクセス試行APIアクセス許可要求

APIアクセス許可

APIアクセス


Webサイト

ユーザー認証


API

サーバー


アイデンティティ・プロビジョニング


APP




サービス


Webサイト

エンドユーザー /

管理者

ユーザー情報追加・変更・削除

ユーザー情報同期


API

サーバー

オープン標準 “FIDO” “SAML” “OpenID Connect” “OAuth” “SCIM”


APP




サービス

アクセス試行

サービス提供

ユーザー認証



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/

http://www.jpmorganchase.com/corporate/annual-report/2015/index.html



ID/パスワードではなく「トークン」を渡す

コンテンツ/

機能Webサイト

モバイルAPIID/パスワード


ID/パスワード

外部向け

API




APP

トークン

管理ID/パスワード +

権限委譲

トークン発行

トークン


「アクセストークン」によるAPIアクセス認可のフレームワーク

APIアクセス認可: OAuth

リソースオーナー

リソース

サーバー

APP

認可

サーバー

クライアント

HTML5

WEBSITE

0

0. リソースへのアクセスを

リクエスト

11. 認可

リクエスト

2

2. ユーザー認証 &

クライアントへの権限委譲の確認

33. OK!

44. アクセストークン

提供

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

https://www.scribd.com/doc/298569302/The-Open-Banking-Standard


国内外の金融機関が、すでに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

http://docs.fidor.de/#understand-oauth

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/

https://tools.ietf.org/html/rfc6749

https://api.slack.com/docs/oauth-scopes

https://azure.microsoft.com/ja-jp/documentation/articles/active-directory-v2-tokens/


OpenID Connect


API

サーバー

OAuthはID連携にも使える?

OAuth仕様が標準化する対象は「アクセストークン」のやりとりであり、「認証依頼」と「認証結果提供」のやりとり、そして「認証結果」（ID情報）の定義は書かれていない


APP




サービス



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との親和性、

モバイル対応

動的なクライント

登録

http://civics.com/OpenID-connect-webinar/


FIDO


「ローカル認証」と「オンライン認証」を分離ユーザー検証はローカルに行い、ユーザー検証結果のみがオンラインに流れる

FIDO認定試験を定期的に開催し、製品・サービスの相互運用性を強化

ユーザー認証: FIDO

Source: “FIDO技術のさらなる広がり” https://fidoalliance.org/wp-content/uploads/FIDOTokyoSeminar-gomi-112015-ja.pdf

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

http://www.slideshare.net/FIDOAlliance/fido-certification


まとめ


アイデンティティ技術を活用した「利用者本位のAPI提供」に向けて

API

サーバー


APP




サービス

アクセス試行

サービス提供

ユーザー認証



APIアクセス


Webサイト

アクセス試行


FIDO: 利用者が使いやすく確実な認証手段を活用できるようになる

OAuth: 利用者が自身の情報の第三者利用をコントロールしやすく

なる

OpenID Connect:利用者が自身のIDを他事業者のサービスでも使えるようになる

Tatsuo [email protected]

https://www.linkedin.com/in/tatsuokudo

@tkudos

mailto:[email protected]

https://www.linkedin.com/in/tatsuokudo

利用者本位のapi提供に向けたアイデンティティ（id）標準仕様 …

Documents