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を専門とするコンサルティングに従事
自己紹介

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

以前からWebサービス間の相互運用標準も存在していた
Source: WS-IがWebサービス相互運用性ガイドラインBasic Profile 1.0を一般公開
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

最近のAPIは利用者本位の連携
会員情報の登録
を登録お客さまの
1. パートナーサイトの
会員情報に、自分の
「ECサイトのID」を登録
「ECサイトID」
パートナーサイト
会員情報の登録
ECサイトID: taro@example.jp
4. 登録完了
2. ECサイトにログイン
ログインキャンセル
ID:
パスワード:
taro@example.jp
********
ECサイト
あなたへのおすすめ商品がありま
す
Powered by 「ECサイト」
•…
•…
•…
パートナーサイトから出ることなく、ECサイトの
商品情報とショッピングカートにアクセス
ECサイト内での行動履歴を元に
パートナー提携ショップでの体験を最適化
パートナーが開発した個別デバイス向け
アプリケーションに情報を提供
ECサイトに登録してあるID情報を用いたパーソナライズや、
ECサイトのカート機能をパートナーに提供
カートに入れる
3. ECサイト上のサービスへ
のアクセスを許可
パートナーが提供するサービス経由で
ECサイトの「ほしい物リスト」
「クチコミ投稿」「カート機能」を
利用できるようにします
OK キャンセル
ECサイト

「利用者本位のAPI連携」のための仕様はOAuth以前にも存在した
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

…が、普及しなかった
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

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

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
2 2. アクセストークン
提供
3
3. アクセストークンを
使ってAPIアクセス
1
1. クライアントのクレデンシャルを
使ってトークンリクエスト ******
アクセストークンを要求
クライアントのクレデンシャルを以て
アクセストークンを提供する

リソースオーナーの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/

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

OAuth 2.0 (RFC 6749) の「リソース・オーナー・パスワード・
クレデンシャル・グラント」 ※非推奨
「リソースオーナーのID/パスワード」をもとに付与した
「トークン」でAPIアクセスを制限する
リソース
サーバー
APP
認可
サーバー
クライアント
HTML5
WEBSITEWEBSITE
0
0. ID/パスワードを登録
パスワード: ******
2 2. アクセストークン
提供
3
1
1. クライアントのクレデンシャルと
ユーザーのID/パスワードを
使ってトークンリクエスト
クライアントのクレデンシャル: ******
パスワード: ******
リソースオーナーのクレデンシャル
を以てアクセストークンを提供する

APIアクセスを制限するための「トークン」を、リソースオーナーの
確認をふまえた「認可コード」をもとに付与する
リソース
サーバー
認可
サーバー
クライアント
WEBSITE
0
0. リソースへのアクセスを
リクエスト
7
ユーザーエージェント
1
1. 認可リクエスト
（ブラウザ
リダイレクト）
2
2. ユーザー認証 & クライアントへの権限委譲の確認
4
4. 認可コード提供
（ブラウザリダイレクト）
6
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

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/
ニュースサイトでの記事の例

OAuthをどう使うか

「フレームワーク」であり、適用にはプロファイリングが必要
そもそもOAuth(2.0)はプロトコルではない
リソース
サーバー
認可
サーバー
クライアント
WEBSITE
0 7
1
2
3
4
6
5
認可リクエストの形式
リソースオーナーの認証・同意方法
トークンリクエスト
の形式
トークンレスポンス
の形式
アクセストークンの
ライフサイクル
アクセストークンの
利用方法
******
クライアント
認証の方式

OAuthプロファイリング101: ブラウザリダイレクト
リソース
サーバー
認可
サーバー
クライアント
WEBSITE
0 7
2
3
4
6
5 ******
4. 認可コード
提供（ブラウザ
（ブラウザ
1

ありがち? なシナリオ (1 of 3)
金融機関と連携する家計簿サイト
利用者（家計簿サイトにログイン済み）
口座情報
API
認可
サーバー
家計簿サイト
WEBSITE
0
0. 金融機関との口座情報
連携をリクエスト
1
（ブラウザ
2
2. （ログイン後）「家計簿サイトか
らのアクセスを許可しますか?」
3
3. OK!
金融機関
利用者として
ログイン
4
5
5. 認可コードを使っ
てトークンリクエスト
******
6
6. アクセストークン
提供
7

家計簿サイトを騙るフィッシングメールを使って…
口座情報
API
認可
サーバー
偽の家計簿サイト
WEBSITE
0
0. 「偽の家計簿サイト」に
アクセスし、再連携を実行
1
（ブラウザ
2
3
3. OK!
金融機関
攻撃者
From: 家計簿サイト
「金融機関との接続
が切れました。再連
携を行ってください」
4
認可コードを
ゲット

他人の口座情報にアクセスできる
攻撃者（家計簿サイトにログイン済み）
口座情報
API
認可
サーバー
家計簿サイト
WEBSITE
0
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%2F
client%2Eexample%2Ecom%2Fcb
HTTP/1.1
Host: server.example.com
4. 認可レスポンス
HTTP/1.1 302 Found
Location:
https://client.example.com/cb
?code=SplxlOBeZQQYbYS6WxSbIA&
state=3af23asl0989gnv

仕様上はクライアントのリダイレクション・エンドポイントを
認可サーバーに事前登録すべき (SHOULD)
これを認可サーバーはどう解釈するか?
1. 事前登録不要。認可サーバーはクライアントが認可リクエ
スト時に指定した任意のURIに認可コードを戻す
2. リダイレクション・エンドポイントのFQDNのみ事前登録。
URIパスやパラメーターの動的追加を許容する
3. リダイレクション・エンドポイントのドメインのみ事前登録。
サブドメインの動的指定を許容する
4. リダイレクション・エンドポイントとして完全なURIを事前登
録。それと一致しないURIは指定不可
クライアントの
「リダイレクション・エンドポイント」 (cont.)
リソース
オーナー
認可
サーバー
クライアント
WEBSITE
ユーザー
エージェント
32
GET /authorize?
response_type=code&
HTTP/1.1
HTTP/1.1 302 Found
Location:
redirect_uriを
どう扱うか?

もう一度、パラメーターレベルで見てみよう
口座情報
API
認可
サーバー
偽の家計簿サイト
WEBSITE
0
0. 「偽の家計簿サイト」に
アクセスし、再連携を実行
金融機関
攻撃者
From: 家計簿サイト
「金融機関との接続
が切れました。再連
携を行ってください」
1
（ブラウザ
GET /authorize?
response_type=code&
client_id=家計簿サイト&
redirect_uri=偽の家計簿サイトのURI
HTTP/1.1
Host: 金融機関

（実例）

ありがち? なシナリオその2 (1 of 3)
認可コードを家計簿サイトに送信せずに…
ログイン
API
認可
サーバー
家計簿サイト
WEBSITE
0
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
GET /authorize?
response_type=code&
HTTP/1.1
HTTP/1.1 302 Found
Location:

仕様上はstateパラメーターの利用を推奨
(RECOMMENDED)
これをクライアントはどう解釈するか?
1. “RECOMMENDED” であり、設定しなくても良い
2. クライアントはすべての認可リクエストに同じstate
値をセットする
3. クライアントは認可リクエストごとにstate値をセット
する
a. セッションIDをセットする
b. セッションIDのハッシュなどをセットする
認可リクエストの “state” パラメーター (cont.)
リソース
オーナー
認可
サーバー
クライアント
WEBSITE
ユーザー
エージェント
32
GET /authorize?
response_type=code&
HTTP/1.1
HTTP/1.1 302 Found
Location:
クライアントは
stateの値を
どう作るか?

もう一度、パラメーターレベルで
見てみよう
ログイン
API
認可
サーバー
家計簿サイト
WEBSITE
0
0. 外部サイトとのログイン
2
3
3. OK!
外部サイト
攻撃者として
ログイン
4
1
（ブラウザ
GET /authorize?
response_type=code&
client_id=家計簿サイト&
state=攻撃者のログインセッ
ションにひもづく値&
redirect_uri=家計簿サイト
のURI
HTTP/1.1
Host: 外部サイト

もう一度、パラメーターレベルで見てみよう(cont.)
ログイン
API
認可
サーバー
家計簿サイト
WEBSITE
外部サイト
攻撃者
<img src=“https://
家計簿サイト
/.../?code=攻撃者の
認可コード&state=攻
撃者のログインセッ
ションにひもづく値”>
利用者
として
ログイン
1
1. 攻撃者の
認可コードを送信
GET /.../?
state=攻撃者のログインセッションにひもづく値&
code=攻撃者の認可コード
HTTP/1.1
Host: 家計簿サイト

（実例）

使える「車輪」や「車輪の部品」はたくさんある
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.0
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を呼び出し
サービス事業者はエンドユーザーを
認証

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)」を規定

クライアントの「リダイレクション・エンドポイント」
 認可サーバーはクライアントのリダイレクトURIを事前登録すること
 認可サーバーはクライアントからの認可リクエストにredirect_uriパラメー
ターが指定されていない場合には処理を中断すること
 認可サーバーは、認可リクエスト内のredirect_uriパラメーターの値を
事前登録したリダイレクトURIと比較し、完全一致しない場合には
処理を中断すること
認可リクエストの “state” パラメーター
 クライアントは有効なCSRF対策を実装すること
トークンリクエストにおけるクライアント認証
 認可サーバーはTLS双方向認証 or JWSクライアントアサーションを用い
てクライアント認証を行うこと
FAPIにおけるプロファイリングの例
“Part 1: 「読み出し専用」 APIセキュリティ・プロファイル”
リソース
オーナー
認可
サーバー
クライアント
WEBSITE
ユーザー
エージェント
32
14
6
6
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
セッション管理
クライアント登録
サービス・ディスカバリー
署名付きリクエスト
アサーション認証
暗号化/署名/鍵
構造化トークン
ミティゲーション & プルーフ
拡張認可フロー
トークン・イントロスペクション
トークン失効
ユーザー/クライアント認可
オブジェクト記法

[PR]☺
”APIセキュリティ” で検索していただければ幸いです
NRIセキュアの「APIセキュリティコンサルティングサービス」
https://www.nri-secure.co.jp/service/consulting/apisecurity.html

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

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

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (13)

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

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

Mais de Tatsuo Kudo

Mais de Tatsuo Kudo (20)

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