ID連携の標準化仕様紹介とセキュアな実装のためのアプローチ 2021 / Identity Federation Protocols 2021

ID連携の標準化仕様紹介とセキュアな実装のためのアプローチ ritou 2021/9

この資料はチーム内勉強会用に作ったものに色々足してるうちに別物になってしまったものです。

ID連携関連の標準化仕様を知ってもらう、入門編のような立ち位置です。

まずは何かをできるようにするための仕様、セキュリティ強化のための仕様があることを知っていただければ幸いです

ID連携機能のための標準化仕様とユースケース

いきなり OpenID Connect(OIDC)

••でログイン Ϣʔβʔ 3FMZJOH1BSUZ 0QFO*%1SPWJEFS Ϣʔβʔ͸31ʹϩάΠϯ ͍ͨ͠ 01ʹϦμΠϨΫτͯ͠
ೝূΠϕϯτͷ৘ใΛཁٻ ೝূΠϕϯτͷ৘ใΛఏڙ ̏ ϩάΠϯͯ͠ɺ 31ʹଐੑ৘ใΛఏڙ͢Δ͜ͱʹಉҙ 7 ೝূΠϕϯτͷ৘ใΛ༻͍ͯ ϩάΠϯঢ়ଶʹ͢Δ 1 6 2 5 3 4

OPがユーザーの同意の元、 RPにイベント情報と属性情報を提供する仕組み

OpenID Connect (Core) ID連携のためのプロトコル認証”イベント”の情報を受け渡しユーザーの属性情報提供

次は OAuth 2.0

別サービスとの連携 3FTPVSDF0XOFS $MJFOU "VUIPSJ[BUJPO4FSWFS 3FTPVSDF4FSWFS Ϣʔβʔ͸$MJFOUͰผαʔϏε
ͷϦιʔεΛར༻͍ͨ͠ "VUI;4FSWFSʹϦμ ΠϨΫτͯ͠ ϦιʔεΞΫηεΛཁٻ ϦιʔεΞΫηεͷݖݶΛఏڙ ̏ ϩάΠϯͯ͠ɺ $MJFOUʹϦιʔεΞΫηεΛఏڙ͢ Δ͜ͱʹಉҙ 15 3FTPVSDF4FSWFS͔Βऔಘ ͨ͠஋Λར༻͢ΔαʔϏεΛఏڙ 1 6 2 5 3 4

認可サーバーがリソースオーナーの同意の元で、クライアントにリソースアクセスを提供する仕組み

混乱を生むところ登場人物 (目的が違うので名前は違う) ユーザー vs リソースオーナー Relying Party vs Client
OpenID Provider vs AuthZ Server 提供するものイベント情報、属性情報 vs リソースアクセス

OIDC vs “OAuth認証" OIDCのRP OPから受け取った情報に紐づくユーザーをログイン状態にできる OAuthのClient 認可サーバーから受け取ったトークンでリソースサーバー(API)にアクセスするプロフィールAPIにアクセスして受け取った情報に紐づ
くユーザーをログイン状態に”できる場合がある”

OIDC = OAuth 2.0 + Identity Layer ID連携に必要な認証イベント情報のやり取りセキュリティイベント :
5W1H + α 属性情報 : 汎用的なプロフィール情報 OAuth 2.0のトークンのやり取りを拡張属性情報API : 最新の情報を提供 OAuth 2.0のリソースアクセスで実現

OIDCで扱う属性情報 sub: ユーザーやデバイス等の識別子 profile: ニックネーム、氏名、プロフィール、性別、生年月日、アイコン画像、URLなど email: メアド、確認済みフラグ phone number:
電話番号、確認済みフラグ address: 住所

属性情報の表現例

OIDCやOAuth 2.0には関連仕様がいっぱいあるのでいくつか紹介

OIDC Discovery, OIDC Dynamic Registration

ログインに利用するOPって個別に設定が必要だよね…?

Discovery & Dynamic Registration OpenID Connect Discovery エンドユーザーの情報からOPを特定する方法
OPのエンドポイントや仕様のサポート状況を RPが取得するためメタデータ定義 OpenID Connect Dynamic Registration 動的なRP登録

Discoveryの実行例

Dynamic Registration リクエスト/レスポンス例

ユースケース: RP設定の効率化 1. 連携対象として“Google”を選択 2. RPはDiscoveryを行い、Googleのエンドポイントなどを取得 3.
(Dynamic Registration非対応の場合など)必要な情報を手動で設定

ユースケース: “普段利用しているOP”でログイン 1. ユーザーがメールアドレスを送信 2. RPはOP情報を取得、Dynamic Registrationがサポートされていたら自身を登録、内部でも情報を保存
3. 取得した情報(ClientIDなど)を用いてID連携開始

Session Management

OIDCで連携してもOP/RPのセッション状態は同期されない “ID連携時” OP/RP共にログイン状態 “OPでログアウト” RPはログイン状態 (逆もあり得る) “RPでログアウト”
OPはログイン状態 (他にもRPがいたりする)

Session Management関連仕様 Session Management セッションの同期状態を確認 RP-initiated Logout RP
-> OPにログアウトを要求 Front-Channel Logout OP -> RPにフロントチャンネルでログアウトを通知 Back-Channel Logout OP -> RPにバックチャンネルでログアウトを通知

ユースケース: ログイン状態の同期複数ドメインで構成されるサービスで、ID連携時のログイン状態が継続しているかを検証可能シングルログアウト 1 OP :
n RPにも対応可能 (実装によっては3rdPartyCookieなどの動向に注意が必要)

Identity Assurance

検証済みデータの扱い同意の元でサービスに渡せる？身元確認！ユーザー

Identity Assurance OIDCでOPがユーザーの検証済み属性情報を RPに提供するための仕様要求 : どんな情報をどういう目的で欲しい表現
: 検証プロセスの情報 + 属性情報応答 : IDトークンもしくは属性情報API 犯収法、携帯電話不正利用防止法の定義も

検証済み属性情報の例 "verified_claims": { "verification": { “trust_ framework": “jp_
aml” }, "claims": { “given_ name#ja-Hani-JP": “太郎", “family_ name#ja-Hani-JP": "東京", “given_ name#ja-Kana-JP": "タロウ", “family_ name#ja-Kana-JP": "トウキョウ", "birthdate": "1981-01-01" } }

ユースケース: 本人確認情報の流通 OPが決済機能で”本人確認” 本人確認書類の画像やマイナンバーカード (JPKI) RPが確認済みの情報やフラグを利用同様の確認を行うコスト,ユーザーの負担軽減(どこまで許されるかは仕様の対象外)

RISC & CAEP

ID連携後に非同期になるのはセッションだけではない ID連携してから… 接続環境が変わった  (リスク評価できる？) アカウント無効化  (RPは気付ける？)

OIDF Shared Signals and Event WG セキュリティイベント、状態変化等のイベントを共有できるようにする Continuous Access
Evaluation Protocol (CAEP) Mitigating Catastrophic Account Compromise (RISC)

RISC実装例: ID連携解除, 退会の通知 OP側で状態変更を検知したらRPのエンドポイントにWebhookで送信セッション無効化アカウント無効化
退会サービス側は署名検証してから処理

CIBA(シーバ)

Decoupled Authentication 手元のスマホで認証+α 決済では 3D Secure 2.2 にて登場 OIDCの文脈で実現するのがCIBA

CIBAでできること分離された環境によるユースケース Consumption Device: 認証を要求する端末 Authentication Device: 認証を行う端末端末のローカル認証の利用 FIDOとの組み合わせ

コンビニ決済 ×CIBA コンビニで支払い（ポイントカードを出す）手元の端末で  認証とアクセス許可  （店員に見せなくて良い）決済完了

オフラインのユースケース POS端末コールセンター銀行の窓口業務サブスクライブ決済など

ここまでのまとめ ID連携のための仕様のうち、こんなことができるよってのを紹介単純な〜〜でログイン以外にも結構ある標準化された仕様がある＝ユースケースに対するリスクと対策が整理されている ID連携の機能を提供する際はなるべく採用していくべき

ID連携仕様から学ぶ Webアプリケーション間のデータ送受信をセキュアにする方法

セキュリティ強化のための仕様基本仕様 : フレームワーク、最もシンプルな実装拡張仕様既存仕様と組み合わせたり一部を置き換えることで安全性を高めるプロファイル、BCP(Best Current
Practice) 気をつけること！仕様の組み合わせ方！

OAuth 2.0の場合

基本仕様と拡張仕様基本仕様 RFC6749 アクセストークン取得までを定義したフレームワーク RFC6750 Bearerトークンを用いたシンプルなAPI保護拡張仕様 RFC7636 PKCEと呼ばれる、モバイルアプリ実装の攻
撃を防ぐための拡張

基本仕様と拡張仕様 BCP RFC8252 ネイティブアプリのBCP (策定中) SPAのBCP OAuth 2.1 たくさんのBCPと拡張仕様を整理して1つのドキュメントとして整理してい
るもの

OIDC FAPI 金融サービス相当のセキュリティレベルが求められる状況でID連携を提供するためのプロファイル Baseline : 中程度の… Advanced :
高度な…

ここからはFAPIで定義/引用されている仕様からセキュアなWebアプリケーション実装のヒントを紹介します

OIDCで使われている通信直接通信 : Webアプリ間、Webアプリとモバイルアプリ間の通信クライアント認証つきのリクエストアクセストークンにより保護されたリクエスト間接通信 : ブラウザを利用してリダイレクト
GET / POST

クライアント認証共有鍵暗号方式クライアントシークレット(テキスト/バイナリ)を共有公開鍵暗号方式秘密鍵/公開鍵のペアを生成、公開鍵を相手に渡しておく

クライアントシークレットを利用したクライアント認証 1. そのまま送る 1. POSTパラメータ client_ secret_
post 2. Basic認証の形式 client_ secret_ basic 2. 直接送らず、署名生成の鍵として利用 client_ secret_ jwt 1. 署名付きのJWTを生成して指定することで、クライアントシークレットが通信路を流れない

鍵ペアを利用したクライアント認証 private_ key__ jwt 秘密鍵を用いて署名付きJWTを生成受け取った側が公開鍵を用いて署名検証 Mutual
TLS TLSのクライアント証明書の仕組みを利用

リソースアクセス Bearer Token アクセストークンそのまま利用 Sender-Constrained Token Mutual TLS : TLSのクライアント証明書の仕組
みを利用署名付きJWT : アクセストークン発行時に鍵ペアを紐付ける(DPoP)

直接通信のポイント暗号化(Encryption)までは求められないシークレットをそのまま送らない方法が推奨されているトークンを利用する場合も、JWTなどを用いてSender-Constrainedにすることでセキュアにできる

間接通信の保護 GETリクエストクエリパラメータフラグメントの利用: サーバーログにパラメータが含まれないデータをJWT形式にする: 改ざん検知可能

間接通信の保護 POST POSTリクエストフォームデータデータをJWT形式にする: 改ざん検知可能 (3rd Party CookieやSameSite属性の影響に注意)

間接通信の保護直接通信との組み合わせ Push(データを送りたい側がリクエスト) 予めデータをPushしておき、取得したキーをGET/ POSTリクエストに含む Pull(データを受け取る側がリクエスト) GET/POSTリクエストに含んだキーに対して受信側にアクセスしてもらう直接通信を利用することで、複雑な構造のリクエストを表現可能

連続した間接通信の保護「ブラウザで行って戻ってくる」処理例：RP->OP->RPというリダイレクト OIDCの認証フローで一般的 CSRFなどなかなか物騒な世界

連続した間接通信の保護セッションに紐づけた値をクエリで引き回す (state @ OAuth 2.0) セッションに紐づけた値を署名つきJWTで引き回す (OIDC nonce
& JAR)

間接通信のポイントこちらも暗号化(Encryption)までは求められない署名付きリクエストにすることで改ざん検知が可能データをUser-Agent上に流したくない、大きいサイズのデータをやり取りするような場合は直接通信と組み合わせる

ここまでのまとめ OIDCのセキュリティプロファイルや拡張仕様などで言及されている、直接通信/間接通信におけるセキュリティ強化のための方法を紹介した基本的な部分を押さえておけば仕様を読むことがあっても怖くはない…はず

仕様の話があまり出てこなかったが…? OIDCの拡張仕様はたくさんあるが、今回紹介したポイントを細かく組み合わせて作られているものが多い (次回があれば)OIDCのシーケンスに対して “ここを強化するためにはこうする” みたいな解説をしたい

全体のまとめユースケースがある仕様の概要と、セキュリティ強化のための考え方を紹介した ID連携では単にユーザーIDを取得するだけではなく様々な処理の標準化が進められている OIDCの拡張仕様はたくさんあるが、今回紹介したポイントを細かく組み合わせて作られているものが多い

終わり

ID連携の標準化仕様紹介とセキュアな実装のためのアプローチ 2021 / Identity F...

ID連携の標準化仕様紹介とセキュアな実装のためのアプローチ 2021 / Identity Federation Protocols 2021

More Decks by ritou

Other Decks in Technology

Featured

Transcript