API提供におけるOAuthの役割 #apijp

API Meetup Tokyo #13
API提供におけるOAuthの役割
2016年4月8日
NRIセキュアテクノロジーズ株式会社
工藤達雄
〒100-0004
東京都千代田区大手町1-7-2 東京サンケイビル

Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 1
昨今、APIアクセス認可のフレームワークとして
"OAuth" 仕様を使うケースが一般的になっています。
本セッションでは OAuth 適用のトレンドと今後について
紹介します。
はじめに

工藤達雄 http://www.linkedin.com/in/tatsuokudo/ @tkudos
サン・マイクロシステムズ (1998~2008)
野村総合研究所 (2008~)
OpenIDファウンデーション・ジャパン (2013~2014)
NRIセキュアテクノロジーズ (2014~)
自己紹介

なぜOAuth?

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

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

ユーザーはID/パスワードをサードパーティに預けることになる → 認証リスク
サードパーティからの情報漏えいやサードパーティ自身による不正利用の懸念が残る
ユーザーはサードパーティに全権委任することになる → 認可リスク
サードパーティは本来サービスに不要な（過剰な）APIアクセスを行うこともできてしまう
使い勝手が悪い
サードパーティのアクセス有効期間を制御できない
サードパーティにユーザーのID/パスワードを渡す?

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

ユーザーのID/パスワードがサードパーティに漏れない
サードパーティからのID/パスワード流出や不正利用が発生しなくなる
サードパーティに委譲する権限をユーザーが限定できるようになる
ユーザーが指定した範囲・機能のみをサードパーティに許可できる
使い勝手が良くなる
サードパーティごとにAPIアクセスの可否をコントロールできる
トークンを使うと

オープン標準への道のり
 2005年前後、各社はそれぞれ独自のAPIアクセス認可のしくみを策定していた
 Flickr Auth, Google AuthSub, Yahoo! BBAuth, …
 2006年11月、TwitterのエンジニアやOpenIDコミュニティを中心に、API代理認証に
OpenIDを適用できないか議論が始まった
 結果的にOpenIDは適用できなかった
 また当時API代理認証のオープン標準と呼べるものはまだ存在しないことが明らかになった
 2007年4月、少人数にてプロトコル検討が始まった
 同7月には仕様草案の初版をもとに公開の場にて議論されるようになった
 そして同10月、OAuth 1.0の最終ドラフトが公開された
Source: http://oauth.net/about/

Source: I CAN HAD OPEN: OAuth First Summit a Hit! « hueniverse
http://hueniverse.com/2008/07/i-can-had-open-oauth-first-summit-a-hit/

「トークンによる API アクセス認可」の標準仕様
現在のバージョンはOAuth 2.0 (1.0はobsolete)
▪ RFC 6749 The OAuth 2.0 Authorization Framework
▪ RFC 6750 同 Bearer Token Usage
「RESTful API」との親和性が高い
スコープによるアクセス権限指定、Authorizationヘッダの利用など
モダンなクライアント環境を考慮している
Webブラウザだけではなく、モバイルネイティブやJavaScriptなど
OAuth
Source: http://oauth.net/2/

OAuthの基本
登場人物と処理の流れ
リソースオーナー
リソース
サーバー
APP
認可
サーバー
クライアント
HTML5
WEBSITE
0
0. リソースへのアクセスを
リクエスト
1
1. 認可
リクエスト
2
2. ユーザー認証 &
クライアントへの権限委譲の確認
3
3. OK!
4 4. アクセストークン
提供
5
5. アクセストークンを
使ってAPIアクセス

OAuthの基本
クライアントがユーザー（リソースオーナー）の同意に基づき「アクセストークン」を入手するための
一連のフローの起点
レスポンスタイプ: フローは「認可コード」か「インプリシット」か
クライアントID：リクエスト元はどのクライアントか
スコープ（オプション）: どのようなアクセス権限を持つアクセストークンか
OAuth認可リクエスト
クライアント
WEBSITE
認可
サーバー
認可リクエスト
GET /authorize?response_type=code&client_id=s6BhdRkqt3&scope=message.readonly&state=xyz
&redirect_uri=https%3A%2F%2Fblue-sea-697d.quartiers047.workers.dev%3A443%2Fhttps%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com

OAuthの基本
認可サーバーはユーザーエージェントを介して間接的に
クライアントに「認可コード」を返す (C)
 HTTP/1.1 302 Found
Location:
https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz
クライアントは認可サーバーに認可コードを送信する (D)
 POST /token HTTP/1.1
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fblue-sea-697d.quartiers047.workers.dev%3A443%2Fhttps%2Fclient%2Eexample%2Ecom%2Fcb
認可サーバーはクライアントにアクセストークンを返却する (E)
 HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value“
}
認可コード・グラント・フロー
+----------+
| 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)
Source: https://tools.ietf.org/html/rfc6749

OAuthの基本
認可サーバーはアクセストークン
をフラグメントとしてユーザーエー
ジェントに返す (C)
 HTTP/1.1 302 Found
Location:
http://example.com/cb#access_token=2YotnFZFEjr1zCs
icMWpAA
&state=xyz&token_type=example&expires_in=3600
ユーザーエージェントはフラグメ
ントからアクセストークンを取り出し
クライアントに提供する (F, G)
インプリシット・グラント・フロー
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI --->| |
| User- | | Authorization |
| Agent -|----(B)-- User authenticates -->| Server |
| | | |
| |<---(C)--- Redirection URI ----<| |
| | with Access Token +---------------+
| | in Fragment
| | +---------------+
| |----(D)--- Redirection URI ---->| Web-Hosted |
| | without Fragment | Client |
| | | Resource |
| (F) |<---(E)------- Script ---------<| |
| | +---------------+
+-|--------+
| |
(A) (G) Access Token
| |
^ v
+---------+
| |
| Client |
| |
+---------+
Source: https://tools.ietf.org/html/rfc6749

OAuthの基本
Authorizationヘッダに入れる
GET /resource HTTP/1.1
Authorization: Bearer mF_9.B5f-4.1JqM
ボディに入れる
POST /resource HTTP/1.1
Content-Type: application/x-www-form-
urlencoded
access_token=mF_9.B5f-4.1JqM
クエリパラメーターに入れる
https://server.example.com/resource?
access_token=mF_9.B5f-4.1JqM&p=q
アクセストークンの利用（Bearerトークン）
リソース
サーバー
APP
クライアント
HTML5
WEBSITE
アクセストークンを

OAuth 2.0は「プロトコル」ではなく「フレームワーク」
要件に合わせた「プロファイリング」が必要
権限付与ポリシー
パラメーターの動的指定・事前指定
クライアントに提供するフロー
アクセストークンのリフレッシュ、失効ポリシー
…
OAuth 2.0をどうAPIに適用するか

プロファイリング
フローは認可コード・グラントのみ
認可リクエストのパラメーター
にscopeが必須
Slackの例
Source: Using OAuth 2.0 | Slack https://api.slack.com/docs/oauth

スコープは object:action:entity の形式
Slackの例 (cont.)
Source: OAuth Scopes | Slack https://api.slack.com/docs/oauth-scopes

アクセストークンは失効しない
Slackの例 (cont.)

「Bot Userアクセス
トークン」という特別な
アクセストークンがある
Slackの例 (cont.)

ひとつのトークンにスコープ
が追加されていく
APIレスポンスヘッダに現在
トークンに追加されているス
コープ一覧が返ってくる
Slackの例 (cont.)

Google
Google Identity Platform
Microsoft
Azure AD “v2.0 エンドポイント”
B2C, B2B, B2B2EすべてのAPIアクセス認可をOAuth 2.0に統一
Source: Google, Microsoft

RFC 7009 OAuth 2.0 Token Revocation
RFC 7519 JSON Web Token (JWT)
RFC 7521 Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants
RFC 7522 Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and
Authorization Grants
RFC 7523 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants
RFC 7591 OAuth 2.0 Dynamic Client Registration Protocol
RFC 7636 Proof Key for Code Exchange by OAuth Public Clients
RFC 7662 OAuth 2.0 Token Introspection
RFC 7800 Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)
“OAuth 2.0” 以後にProposed Standard RFCとなった仕様

OAuthはユーザー認証にも
使えるか?

アクセストークンは「権限が移譲されたことを示す情報」
であり、認証結果や属性情報ではない
実運用ではアクセストークンに加えてID情報も扱うよう
独自拡張を行なうケースが多い
認可リクエストに要求属性を指定
「アクセストークンレスポンス」にID情報を示すキー/値を追加
アクセストークン自体を構造化し、ID情報を包含
アクセストークンを受け取ってID情報を返却するAPIを提供
→ 標準化できるのでは!?
OAuth仕様には「ID情報」の扱い方は書かれていない
{
"access_token":"mF_9.B5f-4.1JqM",
"token_type":"Bearer",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
}
アクセストークン（レスポンス）の例

OAuth 2.0仕様をベースに「アイデンティティ層」を拡張し、認証結果や属性情報の連携、
セッション管理などのAPIを標準化
OpenID Connect
リライング・パーティ
(RP: ID情報要求側)
Webアプリ
ケーション
モバイル
アプリケーション
ライブラリや
パッケージの導
入が不要
ネイティブ
(non-Web)
アプリでも
利用可能
認証結果/属性情報提供
JWT * によって
セキュアにID情報を提供
* JSON Web Token
アイデンティティ・プロバイダ
(IdP: ID情報提供側)
SSO / アクセス
管理システム
“Self-issued IdP”
OpenID
Connect
対応製品が
続々登場
携帯端末が
IdPに!
認可リクエスト/APIアクセス
OAuth 2.0による
API認可と統合

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

ユーザーの認証イベント
（認証結果）を「IDトークン」として定
義
OAuth 2.0と同一のフローにて、「ア
クセストークン」に加え、新たに「ID
トークン」の要求・提供を定義
また、属性情報を提供する
「ユーザー情報（UserInfo）API」を
定義
OpenID ConnectによるID連携のしくみ
2
2. 認可
リクエスト
ID情報提供側
（アイデンティティ・
プロバイダ）
ID情報要求側
（リライング・
パーティ）
ユーザー
1
1. アクセス
試行
7
7. サービス
提供
3
3. 認証・
同意
4’
4’. 「認可
コード」を
送信
4’’
4’’. 「アクセス
トークン」
「IDトークン」
4
4. 認可レスポンス
（「認可コード」 or
「アクセストークン」
「IDトークン」）
5
5. UserInfo
アクセス
w/ アクセス
トークン
6
6. 属性
情報

ID情報提供側におけるユーザ認証イベントの情報を含む、署名付き
JWT（Signed JSON Web Token）
 「このエンドユーザーは○○で、何時何分に、こういう方法で認証を受け、認
証レベルは○で、…」
ID情報要求側は主に、IDトークンに含まれる以下のクレーム（ID情報提
供側がユーザーに関して表明する情報）を用いて、エンドユーザーのア
クセス認可を行う
 エンドユーザーを識別する値（識別子）
 IDトークンの有効期限
 ユーザ認証を実施した日時
 認証コンテクスト・クラス・リファレンス
 認証手段リファレンス
 その他（ユーザー属性など）
IDトークン
{
"iss": "http://server.example.com",
"sub": "248289761001",
"aud": "s6BhdRkqt3",
"nonce": "n-0S6_WzA2Mj",
"exp": 1311281970,
"iat": 1311280970,
"name": "Jane Doe",
"given_name": "Jane",
"family_name": "Doe",
"gender": "female",
"birthdate": "0000-10-31",
"email": "janedoe@example.com",
"picture": "http://example.com/janedoe/me.jpg"
}
IDトークンの中身の例

Beyond OAuth

ユーザーの立場から見ると、ユーザーは
APIクライアントに対して
定められた範囲内で
自分がオーナーであるリソースへ
自分の代理としてアクセス
を認可している
→ 「他人の代理としてアクセス」するAPIクライアントの認可は!?
そもそもOAuthはなにを「認可」しているのか
リソース
サーバー
APP
認可
サーバー
クライアント
HTML5
W EBS ITE
0
0. リソースへのアクセス
をリクエスト
1
1. 認可
リクエスト
2
2. ユーザー認証 &
クライアントへの権限委譲の確認
3
3. OK!
4 4. アクセス
トークン提供
5
5. アクセストークンを

OAuth 2.0をベースに策定された
「他人からのアクセスの認可」
http://tinyurl.com/umawg
UMA (User Managed Access)
Resource
owner
Resource
server
Authorization
server
Client
Authorization
API
UI
UI
UI
Requesting
party
Protection
API
Authorization
client
Protection
client
RS-specific
API
RS-specific
client
1
5
RPT
6
7
8
3
4
PAT
9
AAT
PAT
PAT
RPT
choose resources to
protect – out of band
set policies –
out of band
AAT
2
1. Resource Server (RS) がリソースセットとスコープをAuthorization Server (AS) に登録 (ongoing)
2. ClientがRSにリソースをリクエスト
3. RSがパーミッションをASに登録
4. ASが「パーミッション・チケット」をRSに返却
5. RSがClientにエラーレスポンスのかたちで「パーミッション・チケット」を返却
6. ClientがASにチケットを送信し、認可データとRPTをリクエスト
7. ASがClientに RPTと認可データを返却 (after optional claim flows)
8. ClientがRSにリソースをリクエスト（RPTを送信）
9. RSがClientにリソース表現を返却
Source: https://kantarainitiative.org/confluence/download/attachments/17760302/UMA-flow.pptx?api=v2

まとめ

OAuth 2.0仕様はAPI公開におけるトークンベースのアクセス認可
の実現に有用
自社のAPIに適用するには「OAuth 2.0認可フレームワーク」の
「プロファイリング」が必要
OAuth 2.0を補完する仕様の策定、OpenID ConnectやUMAなどの
派生がいまも進行中
まとめ

OAuth as a Business Enabler
 さまざまなAPIを提供し、他社サービス経由でユーザーの利用状況を把握
 例: ユーザーのターゲティングを強化し本業である広告収益を最大化
エンド
ユーザー
サービス事業者アカウントでログイン
サービス提供
アカウントを
ひもづけ
（ID連携）
アカウントの
ユーザーと
してAPI利用
サービス提供サービス提供
（API利用事業者）
ダ
イ
レ
ク
ト
チ
ャ
ネ
ル
API
広告
システム
利用
履歴
広告配信
広告
出稿者
広告+
掲載料
さまざまなサービスやアプリケーションに
自社サービスの機能が埋め込まれることにより
ユーザーの行動把握が強化できる

「API インタラクションの軸としてアイデンティティを考えない人
→ ゲーム終了」（クレイグ・バートン）
Source: http://www.slideshare.net/tkudo/cis2011toi/21

API提供におけるOAuthの役割 #apijp

API提供におけるOAuthの役割 #apijp

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to API提供におけるOAuthの役割 #apijp (20)

More from Tatsuo Kudo (19)

API提供におけるOAuthの役割 #apijp