OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawaws

情報セキュリティワークショップ in 越後湯沢 2017

OAuth / OpenID Connectを中心とする

APIセキュリティについて

2017-10-06

工藤達雄Cyber Consulting Services

NRI SecureTechnologies, Ltd.

Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 1

工藤達雄 https://www.linkedin.com/in/tatsuokudo @tkudos

サン・マイクロシステムズ(1998~2008)

野村総合研究所(2008~)

OpenIDファウンデーション・ジャパン(2013~2014)

NRIセキュアテクノロジーズ(2014~)

▪ 現在はデジタル・アイデンティティとAPIを専門とするコンサルティングに従事

自己紹介

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


APIセキュリティ、とりわけアクセス認可に欠かせない

「OAuth」と「OpenID Connect」について、

適用例や仕様策定の動向をもとに、注意すべき

ポイントや活用に向けたヒントをご紹介します。

本プレゼンテーションの内容


APIは新しい!?

Source: 野村総合研究所


事業者によるAPI公開は決して新しいものではない

APIの歴史を振り返ると、嚆矢は2003年に

AmazonがProduct Advertising APIを公開したこ

とに始まると言える。Amazonが公開したこのAPI

によってブログなどにアフィリエイト機能を簡単に

付加できるようになり、一気にAmazonの商圏が

拡大した。Source: FinTechを加速させる APIエコノミーhttps://www.nri.com/~/media/PDF/jp/opinion/teiki/kinyu_itf/2016/itf_201603_6.pdf

https://www.nri.com/~/media/PDF/jp/opinion/teiki/kinyu_itf/2016/itf_201603_6.pdf


以前からWebサービス間の相互運用標準も存在していた

Source: WS-IがWebサービス相互運用性ガイドラインBasic Profile 1.0を一般公開http://www.ws-i.org/docs/press/20030825wsipr.doc

http://www.ws-i.org/docs/press/20030825wsipr.doc


`

最近のAPIは開発者本位のアプローチ

Source: JSON's Eight Year Convergence With XML

https://www.programmableweb.com/news/jsons-eight-year-convergence-xml/2013/12/26

Source: User accounts services

https://www.bbvaapimarket.com/documentation/bbva/accounts

https://www.programmableweb.com/news/jsons-eight-year-convergence-xml/2013/12/26

https://www.bbvaapimarket.com/documentation/bbva/accounts


最近のAPIは利用者本位の連携

会員情報の登録を登録お客さまの

1. パートナーサイトの会員情報に、自分の

「ECサイトのID」を登録

「ECサイトID」

パートナーサイト

会員情報の登録

ECサイトID: [email protected]

4. 登録完了


2. ECサイトにログイン

ログインキャンセル

ID:

パスワード:

[email protected]

********

ECサイト

あなたへのおすすめ商品がありますPowered by 「ECサイト」•… •…•…

パートナーサイトから出ることなく、ECサイトの商品情報とショッピングカートにアクセス

ECサイト内での行動履歴を元にパートナー提携ショップでの体験を最適化

パートナーが開発した個別デバイス向けアプリケーションに情報を提供

ECサイトに登録してあるID情報を用いたパーソナライズや、ECサイトのカート機能をパートナーに提供

カートに入れる




3. ECサイト上のサービスへのアクセスを許可

パートナーが提供するサービス経由でECサイトの「ほしい物リスト」「クチコミ投稿」「カート機能」を

利用できるようにします

OK キャンセル

ECサイト


「利用者本位のAPI連携」のための仕様はOAuth以前にも存在した

8

Source: リバティ・アライアンスの取組みについてhttp://www.kantei.go.jp/jp/singi/it2/nextg/meeting/dai7/siryou4.pdf

相互に連携するWebサービス

を、最終的にサービスを受ける

「利用者」を中心に置いて実行

させるには、すべてのWebサー

ビスが「そのサービスをリクエ

ストしている大元は誰か」を認

識することが必要です。Source:アイデンティティWeb サービス:エンド・ツー・エンドのアイデンティティ連携

http://otn.oracle.co.jp/technology/global/jp/sdn/javasystem/techtopics/identity/200706.html

http://www.kantei.go.jp/jp/singi/it2/nextg/meeting/dai7/siryou4.pdf

http://otn.oracle.co.jp/technology/global/jp/sdn/javasystem/techtopics/identity/200706.html


…が、普及しなかった

Source: Liberty ID-WSF Web Services Framework Overview Version: 2.0

http://www.projectliberty.org/liberty/content/download/889/6243/file/liberty-idwsf-overview-v2.0.pdf

Source: Liberty Specifications Tutorial https://www.itu.int/itudoc/itu-t/com17/tutorial/85606.html

https://www.itu.int/itudoc/itu-t/com17/tutorial/85606.html

http://www.projectliberty.org/liberty/content/download/889/6243/file/liberty-idwsf-overview-v2.0.pdf

https://www.itu.int/itudoc/itu-t/com17/tutorial/85606.html

Copyright © NRI SecureTechnologies, Ltd. All rights reserved.

OAuth


OAuthの誕生

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アクセス認可のしくみは各社各様だった（Flickr Auth,

Google AuthSub, Yahoo! BBAuth, …）2005

• 11月、コミュニティを中心に、API代理認証にOpenIDを適用できないか議論が始まった（結果的に適用できず）2006

• 4月、少人数にてプロトコル検討が始まった

• 7月、仕様草案の初版をもとに公開の場にて議論されるようになった

• 10月、OAuth 1.0の最終ドラフトが公開された2007

http://hueniverse.com/2008/07/i-can-had-open-oauth-first-summit-a-hit/


APIアクセス（フルオープン）

API

サーバー

APP

APIクライアント

HTML5

WEBSITE

1

GET /items/12345 HTTP/1.1


APIアクセスを「クライアントのクレデンシャル」で制限する

API

サーバー

APP


HTML5

WEBSITE

1 ******

GET /items/12345 HTTP/1.1

x-api-key: ******

クライアントのクレデンシャルを要求


OAuth 2.0 (RFC 6749) の「クライアント・クレデンシャル・グラント」

「クライアントのクレデンシャル」をもとに付与した「トークン」でAPIアクセスを制限する

リソース

サーバー

APP

認可

サーバー

クライアント

HTML5

WEBSITE

22. アクセストークン

提供

3

3. アクセストークンを

使ってAPIアクセス

11. クライアントのクレデンシャルを

使ってトークンリクエスト ******

アクセストークンを要求

クライアントのクレデンシャルを以て

アクセストークンを提供する


リソースオーナーのID/パスワードを使ってAPIのアクセスを制限したい場合には?

リソースオーナー

リソース

サーバー

APP

クライアント

HTML5

WEBSITE

0

0. ID/パスワードを登録

ユーザーID: johndoe

パスワード: ******1

1. ID/パスワードを



パスワード: ******

ID/パスワードを要求


「パスワード・アンチパターン」

Source: https://www.flickr.com/photos/factoryjoe/2110461562/ https://www.flickr.com/photos/ronin691/2110909518/

https://www.flickr.com/photos/factoryjoe/2110461562/

https://www.flickr.com/photos/ronin691/2110909518/


ユーザーは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


OAuth 2.0 (RFC 6749) の「リソース・オーナー・パスワード・クレデンシャル・グラント」 ※非推奨

「リソースオーナーのID/パスワード」をもとに付与した「トークン」でAPIアクセスを制限する


リソース

サーバー

APP

認可

サーバー

クライアント

HTML5

WEBSITEWEBSITE

0

0. ID/パスワードを登録


パスワード: ******


提供

3



1

1. クライアントのクレデンシャルと

ユーザーのID/パスワードを

使ってトークンリクエスト

クライアントのクレデンシャル: ******


パスワード: ******


リソースオーナーのクレデンシャル

を以てアクセストークンを提供する


APIアクセスを制限するための「トークン」を、リソースオーナーの確認をふまえた「認可コード」をもとに付与する


リソース

サーバー

認可

サーバー

クライアント

WEBSITE0

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

リクエスト

7



ユーザーエージェント

1

1. 認可リクエスト

（ブラウザ

リダイレクト）

2

2. ユーザー認証 & クライアントへの権限委譲の確認

4

4. 認可コード提供

（ブラウザリダイレクト）

6


提供

3

3. OK!


パスワード: ******

5

5. クライアントの

クレデンシャルと

認可コードを使って

トークンリクエスト

******


認可コードを以て

アクセストークンを提供する


いわゆる “OAuth 2.0”

RFC 6749: OAuth 2.0 認可フレームワーク RFC 6750: OAuth 2.0 認可フレームワーク:

ベアラー・トークンの用法


金融分野のAPIにもOAuth

Source: オープンAPIのあり方に関する検討会報告書－オープン・イノベーションの活性化に向けて－ https://www.zenginkyo.or.jp/fileadmin/res/news/news290713_1.pdf

https://www.zenginkyo.or.jp/fileadmin/res/news/news290713_1.pdf


OAuthはセキュアか?

Source:警報：Google Docフィッシング拡大中――PSAは連絡先全員に偽の招待メールを送る

http://jp.techcrunch.com/2017/05/04/20170503ps

a-this-google-doc-scam-is-spreading-fast-and-will-

email-everyone-you-know/

Source: PayPal Fixes OAuth Token Leaking Vulnerability

https://threatpost.com/paypal-fixes-oauth-token-leaking-

vulnerability/122136/

Source: OAuthとOpenIDに深刻な脆弱性か-

-Facebookなど大手サイトに影響もhttps://japan.cnet.com/article/35047497/

ニュースサイトでの記事の例

http://jp.techcrunch.com/2017/05/04/20170503psa-this-google-doc-scam-is-spreading-fast-and-will-email-everyone-you-know/

https://threatpost.com/paypal-fixes-oauth-token-leaking-vulnerability/122136/

https://japan.cnet.com/article/35047497/


OAuthをどう使うか


「フレームワーク」であり、適用にはプロファイリングが必要

そもそもOAuth(2.0)はプロトコルではない


リソース

サーバー

認可

サーバー

クライアント

WEBSITE0 7


1

2

3

4

6

5

認可リクエストの形式

リソースオーナーの認証・同意方法

トークンリクエスト

の形式

トークンレスポンス

の形式

アクセストークンの

ライフサイクル

アクセストークンの

利用方法

******

クライアント

認証の方式


OAuthプロファイリング101: ブラウザリダイレクト


リソース

サーバー

認可

サーバー

クライアント

WEBSITE0 7


2

3

4

6

5 ******

4. 認可コード

提供（ブラウザ



（ブラウザ


1


ありがち? なシナリオ (1 of 3)

金融機関と連携する家計簿サイト

利用者（家計簿サイトにログイン済み）

口座情報

API

認可

サーバー

家計簿サイト

WEBSITE0

0. 金融機関との口座情報

連携をリクエスト

1


（ブラウザ


2

2. （ログイン後）「家計簿サイトか

らのアクセスを許可しますか?」

3

3. OK!

金融機関

利用者としてログイン

4



5

5. 認可コードを使っ

てトークンリクエスト

******

6


提供

7





家計簿サイトを騙るフィッシングメールを使って…


口座情報

API

認可

サーバー

偽の家計簿サイト

WEBSITE0

0. 「偽の家計簿サイト」に

アクセスし、再連携を実行

1


（ブラウザ


2



3

3. OK!

金融機関

攻撃者

From: 家計簿サイト

「金融機関との接続

が切れました。再連

携を行ってください」

4



認可コードを

ゲット



他人の口座情報にアクセスできる

攻撃者（家計簿サイトにログイン済み）

口座情報

API

認可

サーバー

家計簿サイト

WEBSITE0

0. 金融機関と

の口座情報連

携をリクエスト

1


（ブラウザ


2



3

3. OK!

金融機関

他人の

認可コード

攻撃者としてログイン

8


使って他人の口座情報

にアクセス

4



7

7. 他人の口座情報に

アクセス可能なアクセス

トークンを提供

6

6. 認可コードを

使ってトークン

リクエスト

******

5

5. リダイレクトを

中断し他人の

認可コードを送信すり替え


クライアント側に用意する「認可コードの

受け口」

クライアントが認可リクエストを認可サーバー

に送信する際、どの「リダイレクション・エンドポ

イント」に認可コードを戻してほしいかを指定

認可サーバーは「リダイレクション・エンドポイ

ントへのリダイレクトレスポンス」として認可

コードを返却し、ユーザーエージェントがそれ

を自動的に送信（≒転送）

クライアントの「リダイレクション・エンドポイント」


認可

サーバー

クライアント

WEBSITE


リダイレクション

エンドポイント

32


GET /authorize?response_type=code&client_id=s6BhdRkqt3&scope=message.readonly&state=3af23asl0989gnv&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

HTTP/1.1Host: server.example.com

4. 認可レスポンス

HTTP/1.1 302 FoundLocation: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=3af23asl0989gnv


仕様上はクライアントのリダイレクション・エンドポイントを

認可サーバーに事前登録すべき (SHOULD)

これを認可サーバーはどう解釈するか?

1. 事前登録不要。認可サーバーはクライアントが認可リクエ

スト時に指定した任意のURIに認可コードを戻す

2. リダイレクション・エンドポイントのFQDNのみ事前登録。

URIパスやパラメーターの動的追加を許容する

3. リダイレクション・エンドポイントのドメインのみ事前登録。

サブドメインの動的指定を許容する

4. リダイレクション・エンドポイントとして完全なURIを事前登

録。それと一致しないURIは指定不可

クライアントの「リダイレクション・エンドポイント」 (cont.)


認可

サーバー

クライアント

WEBSITE






32




redirect_uriをどう扱うか?


もう一度、パラメーターレベルで見てみよう


口座情報

API

認可

サーバー

偽の家計簿サイト

WEBSITE0

0. 「偽の家計簿サイト」に

アクセスし、再連携を実行

金融機関

攻撃者

From: 家計簿サイト

「金融機関との接続

が切れました。再連

携を行ってください」

1


（ブラウザ


GET /authorize?response_type=code&client_id=家計簿サイト&scope=message.readonly&state=3af23asl0989gnv&redirect_uri=偽の家計簿サイトのURIHTTP/1.1Host: 金融機関


（実例）


ありがち? なシナリオその2 (1 of 3)

認可コードを家計簿サイトに送信せずに…

ログイン

API

認可

サーバー

家計簿サイト

WEBSITE0

0. 外部サイトとのログイン


1


（ブラウザ


2

2. （ログイン後）「家計簿サイトへ

のログインを許可しますか?」

3

3. OK!

外部サイト



4





その認可コードを他人に送信させる

ログイン

API

認可

サーバー

家計簿サイト

WEBSITE

外部サイト

攻撃者

<img src=“https://

家計簿サイト

/.../?code=攻撃者

の認可コード”>


1

1. 攻撃者の

認可コードを送信


2

2. 攻撃者の認可コードを


******

3

3. 攻撃者のログイン情報に

アクセス可能なアクセス


4


使って攻撃者のログイン

情報にアクセス

5

5. 攻撃者のログイン

情報を返却

6 6. 利用者のアカウン

トと攻撃者のログイン

情報とがリンク



他人になりすまして家計簿サイトにログイン完了

ログイン

API

認可

サーバー

家計簿サイト

WEBSITE

1


（ブラウザ


2



3

3. OK!

外部サイト


4



5

5. 攻撃者の認可コードを


****** 6

6. 攻撃者のログ

イン情報にアクセ

ス可能なアクセス


7


使って攻撃者のログイン

情報にアクセス

8

8. 攻撃者のログイン

情報を返却

9

9. 利用者として

ログイン完了

0

0. 外部サイトのIDを使った

ログインをリクエスト外部サイトのログイン

情報とのひもづけ


クライアントが認可リクエストのパラ

メーターとして設定する値

認可リクエストにstateパラメーターの

値が設定されていた場合、認可サー

バーはその値を認可レスポンスに設

定する

クライアントはこの値を用いて、送信し

た認可リクエストと、受信した認可レス

ポンスとをひもづけることができる

認可リクエストの “state” パラメーター


認可

サーバー

クライアント

WEBSITE




32







仕様上はstateパラメーターの利用を推奨

(RECOMMENDED)

これをクライアントはどう解釈するか?

1. “RECOMMENDED” であり、設定しなくても良い

2. クライアントはすべての認可リクエストに同じstate

値をセットする

3. クライアントは認可リクエストごとにstate値をセット

する

a. セッションIDをセットする

b. セッションIDのハッシュなどをセットする

認可リクエストの “state” パラメーター (cont.)


認可

サーバー

クライアント

WEBSITE




32






クライアントはstateの値をどう作るか?


もう一度、パラメーターレベルで見てみよう

ログイン

API

認可

サーバー

家計簿サイト

WEBSITE0

0. 外部サイトとのログイン


2



3

3. OK!

外部サイト



4



1


（ブラウザ


GET /authorize?response_type=code&client_id=家計簿サイト&scope=message.readonly&state=攻撃者のログインセッションにひもづく値&redirect_uri=家計簿サイトのURIHTTP/1.1Host: 外部サイト


もう一度、パラメーターレベルで見てみよう(cont.)

ログイン

API

認可

サーバー

家計簿サイト

WEBSITE

外部サイト

攻撃者

<img src=“https://

家計簿サイト

/.../?code=攻撃者の

認可コード&state=攻

撃者のログインセッ

ションにひもづく値”>



1

1. 攻撃者の

認可コードを送信

GET /.../?state=攻撃者のログインセッションにひもづく値&code=攻撃者の認可コードHTTP/1.1Host: 家計簿サイト


（実例）


使える「車輪」や「車輪の部品」はたくさんある

OAuthの拡張仕様など https://datatracker.ietf.org/wg/oauth/documents/

OpenID Connect http://openid.net/developers/specs/

For starters…

RFC 6819: OAuth 2.0の脅威モデルとセキュリティ検討https://tools.ietf.org/html/rfc6819, https://openid-foundation-japan.github.io/rfc6819.ja.html （和訳）

draft-ietf-oauth-security-topics: OAuthセキュリティ・トピックスhttps://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics

RFC 8252: ネイティブ・アプリケーション向けのOAuth 2.0https://tools.ietf.org/html/rfc8252

プロファイリングをどう進めていくか?

https://datatracker.ietf.org/wg/oauth/documents/

http://openid.net/developers/specs/

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

https://openid-foundation-japan.github.io/rfc6819.ja.html

https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics

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


OAuth周辺の動向（OpenID Connect, FAPI）


API

サーバー

OAuth仕様には「認証依頼」と「認証結果提供」のやりとり、そして「認証結果」（ID情報）の定義は書かれていない

エンドユーザー

APP

サードパーティ


（Webサイトなど）

サービス

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

APIアクセス許可

APIアクセス


Webサイト

ユーザー認証

アクセス試行

認証依頼認証結果提供

アイデンティティ連携サードパーティに「いまアクセス

してきたユーザーに関する情報」を提供する

APIアクセス認可(OAuth)

サードパーティに「ユーザーに成り代わってアクセスをするための許可証」を提供する

扱う情報が異なる


API

サーバー

OAuth 2.0仕様をベースに「アイデンティティ層」を拡張し、認証結果や属性情報の連携、セッション管理などのAPIを標準化

アイデンティティ連携: OpenID Connect (OIDC)

エンドユーザー

APP



（Webサイトなど）

サービス

アクセス試行

APIアクセス許可要求+ 認証依頼

APIアクセス許可+ 認証結果提供

APIアクセス

ユーザー認証

認証結果（IDトークン）

• ID情報提供側におけるユーザ

認証イベントの情報

• エンドユーザーを識別する値

（識別子）

• IDトークンの有効期限

• ユーザ認証を実施した日時

• 認証コンテクスト・クラス・

リファレンス

• 認証手段リファレンス

• その他（ユーザー属性など）

• 署名付きJWT（Signed JSON

Web Token）として表現


金融機関（サービス事業者）

資産管理サービスにおけるOAuth 2.0とOpenID Connect (OIDC) を用いた認証・認可フローの例

NRI ITソリューションフロンティア Vol.33 No.08 https://www.nri.com/~/media/PDF/jp/opinion/teiki/it_solution/2016/ITSF160802.pdfに加筆

サードパーティはAPIアクセス許可依頼とユーザー認証依頼を同時に実行

口座所有者（エンドユーザー）

資産管理FinTech企業（サードパーティ）

サービス事業者はエンドユーザーにアクセス許可を確認

サービス事業者はサードパーティに「アクセストークン（APIアクセス許可

情報）」と「IDトークン（認証結果）」を返却

サードパーティは認証結果をもとにエンドユーザーの当人確認を行い、必要に応じてユーザーを新規登録

サードパーティはアクセストークンを用いてサービス事業者のAPIを呼び出し

サービス事業者はエンドユーザーを認証

https://www.nri.com/~/media/PDF/jp/opinion/teiki/it_solution/2016/ITSF160802.pdf


OpenID Foundation “Financial API (FAPI) WG”http://openid.net/wg/fapi/

策定を進めている仕様

APIセキュリティ・プロファイル

▪ Part 1: 「読み出し専用」API

▪ Part 2: 「読み書き」 API

API仕様

▪ Part 3: オープンデータAPI

▪ Part 4: 保護対象データAPIおよびスキーマ - 「読み出し専用」

▪ Part 5: 保護対象データAPIおよびスキーマ - 「読み書き」

認可サーバー、クライアント、

リソースサーバーに対する

「セキュリティ条項 (Security

Provisions)」を規定

http://openid.net/wg/fapi/


クライアントの「リダイレクション・エンドポイント」

認可サーバーはクライアントのリダイレクトURIを事前登録すること

認可サーバーはクライアントからの認可リクエストにredirect_uriパラメー

ターが指定されていない場合には処理を中断すること

認可サーバーは、認可リクエスト内のredirect_uriパラメーターの値を

事前登録したリダイレクトURIと比較し、完全一致しない場合には

処理を中断すること

認可リクエストの “state” パラメーター

クライアントは有効なCSRF対策を実装すること

トークンリクエストにおけるクライアント認証

認可サーバーはTLS双方向認証 or JWSクライアントアサーションを用い

てクライアント認証を行うこと

FAPIにおけるプロファイリングの例“Part 1: 「読み出し専用」 APIセキュリティ・プロファイル”


認可

サーバー

クライアント

WEBSITE




32

14

66

5 ******

リダイレクション・エンドポイントの厳密なチェック

クライアント認証はBasic認証不可

CSRF対策（i.e. 適切なstateの利用）


まとめ


「ビジネス・モーメント」と「エコシステム」

ビジネス・モーメント顧客に対してその瞬間に最も必要なサービスをエンドユーザー自発的な同意に基づいて提供

エコシステム自社顧客へのサービスに他社のAPIを活用し

一方で別の事業者の顧客接点に対してAPIを提供

APIファースト企業が自社のコアを外部に開放し、その機能を他社が取り込み、

エンドユーザーに対していままで提供できていなかった、イノベーティブな価値やソリューションを創造するためのしくみ

アイデンティティ & API セキュリティスタック


これからのアイデンティティ & API セキュリティスタック

Source: Forging a Modern Cloud-first Identity Ecosystem for a 125-year-old Startup

https://www.slideshare.net/identityhutch/forging-a-modern-cloudfirst-identity-ecosystem-for-a-125yearold-startup

アイデンティティ & 認証コンテクスト

アイデンティティAPI

セッション管理

クライアント登録

サービス・ディスカバリー

署名付きリクエスト

アサーション認証

暗号化/署名/鍵

構造化トークン

ミティゲーション & プルーフ

拡張認可フロー

トークン・イントロスペクション

トークン失効

ユーザー/クライアント認可

オブジェクト記法

https://www.slideshare.net/identityhutch/forging-a-modern-cloudfirst-identity-ecosystem-for-a-125yearold-startup


[PR]☺

”APIセキュリティ” で検索していただければ幸いです

NRIセキュアの「APIセキュリティコンサルティングサービス」https://www.nri-secure.co.jp/service/consulting/apisecurity.html

https://www.nri-secure.co.jp/service/consulting/apisecurity.html

Internet

OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawaws