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

by ritou

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

いきなり OpenID Connect(OIDC)

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

次は OAuth 2.0

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

属性情報の表現例

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

OIDC Discovery, OIDC Dynamic Registration

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

Discoveryの実行例

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

Session Management

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

Identity Assurance

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

検証済み属性情報の例 "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" } }

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

RISC & CAEP

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

CIBA(シーバ)

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

OAuth 2.0の場合

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

FAPI

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

終わり