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~)

自己紹介

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


なぜ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/

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/

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/

http://oauth.net/2/


OAuthの基本

登場人物と処理の流れ

リソースオーナー

リソース

サーバー

APP

認可

サーバー

クライアント

HTML5

WEBSITE

0

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

リクエスト

1

1. 認可

リクエスト

2

2. ユーザー認証 &

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

33. OK!

44. アクセストークン

提供

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%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

Host: server.example.comAuthorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JWContent-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

認可サーバーはクライアントにアクセストークンを返却する (E) HTTP/1.1 200 OK

Content-Type: application/json;charset=UTF-8Cache-Control: no-storePragma: 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

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


OAuthの基本

認可サーバーはアクセストークン

をフラグメントとしてユーザーエー

ジェントに返す (C) HTTP/1.1 302 FoundLocation: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA

&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

http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA

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


OAuthの基本

Authorizationヘッダに入れる

GET /resource HTTP/1.1Host: server.example.comAuthorization: Bearer mF_9.B5f-4.1JqM

ボディに入れる

POST /resource HTTP/1.1Host: server.example.comContent-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

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



スコープは object:action:entityの形式

Slackの例 (cont.)

Source: OAuth Scopes | Slack https://api.slack.com/docs/oauth-scopes

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

モバイル対応

動的なクライント

登録

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


ユーザーの認証イベント

（認証結果）を「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": "[email protected]",

"picture": "http://example.com/janedoe/me.jpg"

}

IDトークンの中身の例


Beyond OAuth


ユーザーの立場から見ると、ユーザーは

APIクライアントに対して

定められた範囲内で

自分がオーナーであるリソースへ

自分の代理としてアクセス

を認可している

→ 「他人の代理としてアクセス」するAPIクライアントの認可は!?

そもそもOAuthはなにを「認可」しているのか


リソース

サーバー

APP

認可

サーバー

クライアント

HT ML 5

W EB S ITE

0

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

をリクエスト

1

1. 認可

リクエスト

2

2. ユーザー認証 &

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

33. OK!

44. アクセス

トークン提供

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

ProtectionAPI

Authorization client

Protectionclient

RS-specificAPI

RS-specific client

1

5RPT

6

7

8

3

4

PAT

9

AAT

PAT

PAT

RPT

choose resources toprotect – out of band

set policies –out of band

AAT

21. 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

http://tinyurl.com/umawg

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

http://www.slideshare.net/tkudo/cis2011toi/21

Internet

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