狠狠撸

狠狠撸Share a Scribd company logo

Mobage Connect と Identity 関連技術への取り組み - OpenID Summit Tokyo 2015

?
?
Toru Yamaguchi
Toru Yamaguchi

OpenID Summit Tokyo 2015 での発表資料です。

1 of 29
Download to read offline
Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? Mobage Connect と Identity 関連技術への 取り組み OpenID Summit 2015 November ?10, ?2015 ? Toru ?Yamaguchi ? Senior ?Architect ? ? Sub ?Business ?Unit ?Head ? Open ?Pla=orm ?Business ?Unit ? DeNA ?Co., ?Ltd. ? ?
Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? 講演者紹介 ? !? ?氏名 ? ?? ?山?口 ?徹 ?(やまぐち ?とおる) ? !? HN ? ?? @zigorou ? !? 会社 ? ?? 株式会社ディー?エヌ?エー ? !? 部署 ? ?? オープンプラットフォーム事業本部 ? !? 役職 ? ?? 副事業本部??長 ?シニアアーキテクト ? !? 仕事 ? ?? Mobage ?やその他協業案件などにおける システム設計がメイン ? 2 ?
Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? 本?日の概要 ? !? Mobage ?Connect ?(OpenID ?Server) ?の構築経験で、?工夫した点とし て以下の話をしていきます ? ?? CSRF ?Token ?への ?JWT ?の利利?用 ? ?? Access ?Token ?への ?JWT ?の利利?用と ?Microservices ? ?? Intent ?URI ?Scheme ?と ?Browser ?– ?Native ?App ?連携 ? !? 実践的な話につき ?JWT ?などの ?Identity ?技術の基本的な話はあまりし ません ? 3 ?
Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? CSRF ?Token ?への ?JWT ?の利利?用 ? Mobage ?Connect ?と ?Identity ?関連技術への取り組み ? 4 ?
Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? CSRF ?(Cross ?Site ?Request ?Forgery) ? !? CSRF ?とは上記のような攻撃?手法です ? ?? 例例えば、ログイン状態で所定の?手続きを経ないと本来出来ない?行行 為を強制的に?行行わせるといった事に使われます ? !? このような攻撃が成?立立させない為に?行行う対策の?一つとして ?CSRF ?Token ?の発?行行と検証があります ? 5 ? 事前の信頼関係 ? (セッションの確?立立) ? 1. ? ? 2. ? 3. ? 良良くある ?CSRF ?の例例として、 ? 1.? 何らかの悪意のある ?URL ?を踏ませる ? 2.? 正規の ?Web ?サーバーに対する不不正な リクエストを送出させるようなコンテ ンツを返却する ? 3.? ユーザーが意図しないうちに、不不正な リクエストが送信される ? 正規のWeb ?サーバー ? 悪意のある ?Web ?サーバー ?
Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? 良良くある ?CSRF ?Token ?の仕組み ? !? Page ?A ?で ?Page ?Token ?を発?行行し、それを ?Cache ?Server ?(例例えば ? memcached ?や ?Redis ?のようなサーバー) ?に保存し、Page ?Token ?が 無いと ?Page ?B ?が?見見れないようにする ? ?? 消費するたびに ?Cache ?から削除すればワンタイム性が得られる ? 6 ? hIp://goo.gl/Wfvcz0 ?
Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? 良良くある ?CSRF ?Token ?の課題点 ? !? 普段使う分には?大した問題ではないのですが、?大規模サービスだとあ ながちバカに出来ない課題があります ? ?? CSRF ?Token ?の発?行行?検証時に ?Cache ?Server ?とのラウンドトリ ップが必ず発?生してしまうこと ? ?? また ?CSRF ?Token ?の有効期限内、必ず ?Cache ?Server ?に ?CSRF ? Token ?が存在するようにしておかなければならない ? ?? Cache ?Server ?はしばしば ?eviction ?によってデータがロストする ? ?? どのページで発?行行された ?CSRF ?Token ?かをあまり検証していない ケースが多い ? ?? 不不正に ?CSRF ?Token ?が?入?手されると、クリティカルなページへのリクエ ストに利利?用され兼ねない ? !? そこで ?JWT ?を利利?用します！ ? 7 ?
Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? CSRF ?Token ?の ?JWT ?Claims ?表現 ? !? /typ ?に ?csrf_?token ?と明記し、/_?ext ?に拡張データを?入れています ? ?? /_?ext/a ?は ?Page ?Token ?の発?行行ページの ?id ? ?? /_?ext/t ?は ?Tracking ?Cookie ?の ?Hash ?値 ? ?? /_?ext/p ?は ?hidden ?パラメータ等の埋め込み ?(改ざん防?止) ? 8 ? (注意) ?実際の ?Mobage ?Connect ?の ?CSRF ?Token ?と?一部フォーマットが異異なります ?
Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? Cache ?サーバーは利利?用された際に使う ?(まだ構想段階) ? !? 基本的には ?JWT ?の ?iat ?+ ?有効期限に収まっているかをチェックする ? ?? アルゴリズムでの評価 ? !? 有効期限内の場合は ?Cache ?に ?invalidate ?情報が無い場合は未利利?用なので ? veri?ed ?とする ? ?? ある場合は利利?用済みなので ?not ?veri?ed ?とする ? 9 ? CSRF ?Token ?(JWT) ?の有効期限 ? (受け?入れページごとに定義) ? Cache ?に ?invalidate ?された ? JWT ?の ?jU ?値を格納する ? 発?行行 ? 検証 ? 有効期限 ?
Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? Source ?AcMon ?と ?DesMnaMon ?AcMon ?(1) ? !? CSRF ?Token ?の ?/_?ext/a ?に埋め込まれた値 ?sa1 ?に対して ? ?? da1 ?では ?sa1 ?で発?行行された ?CSRF ?Token ?を受け付ける ? ?? da2, ?da3 ?では ?Reject ?される ? 10 ? Source ?(sa1) ? Source ?(sa2) ? Source ?(sa3) ? Dest ?(da1) ? accept ?(sa1) ? Dest ?(da2) ? accept ?(sa2) ? Dest ?(da3) ? accept ?(sa2, ?sa3) ? Reject ? Reject ?
Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? Source ?AcMon ?と ?DesMnaMon ?AcMon ?(2) ? !? アクセス可能な関係値は上記のようになります ? ?? 受け?入れる ?Action ?のホワイトリストを ?WAF ?の ?Router ?設定に 記述しています ? 11 ? Source ?(sa1) ? Source ?(sa2) ? Source ?(sa3) ? Dest ?(da1) ? accept ?(sa1) ? Dest ?(da2) ? accept ?(sa2) ? Dest ?(da3) ? accept ?(sa2, ?sa3) ?
Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? その他の拡張ポイント ? !? Tracking ?Cookie ?検証 ? ?? CSRF ?Token ?が仮に他者に奪われても ?Tracking ?Cookie ?のハッ シュ値が?一致しない限りは ?Reject ?されます ? !? 埋め込みパラメータの検証 ? ?? 特に ?submit ?前の ?form ?には ?input[@type=“hidden”] ?のような 埋め込みパラメータが良良く使われます ? ?? これらの値が改ざんされないように、JWT ?中に ?object ?として埋 め込み、実際に送信されたデータと?比較して、内容が改ざんされ ていれば ?Reject ?します ? 12 ?
Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? Access ?Token ?への ?JWT ?の利利?用と ?Microservices ? Mobage ?Connect ?と ?Identity ?関連技術への取り組み ? 13 ?
Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? Microservices ?と ?Access ?Token ?の相性が悪い件 ? !? Microservices ?はサービスごとに独?立立したインスタンスや ?DB ?を持ち、 API ?をインターフェースとして結合する ?Thin ?なやり?方 ? ?? そのようなケースで ?Token ?DB ?をどう参照するのか？ ? 14 ? AuthZ ?Server ? Token ?DB ? Client ? Resource ?Server ? Token ? ? Endpoint ? 1. ?Token ?Request ? 3. ?Token ?Response ? 2. ?Store ?Token ? 4. ?Request ?to ? ? Resource ?Server ? 異異なるネットワークにある ? Token ?DB ?をどう参照するか？ ?
Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? OAuth ?2.0 ?Token ?IntrospecMon ?(RFC ?7662) ? !? Introspection ?Endpoint ?で ?Access ?Token ?の検証を ?AuthZ ?Server ? に依頼する事が出来る ? ?? これで?一応 ?Microservices ?にも対応出来るようになる ? 15 ? AuthZ ?Server ? Token ?DB ? Client ? Resource ?Server ? Token ? ? Endpoint ? 1. ?Token ?Request ? 3. ?Token ?Response ? 2. ?Store ?Token ? 6. ?Lookup ?Token ? 4. ?Request ?to ? ? Resource ?Server ? IntrospecUon ? Endpoint ? 5. ?IntrospecUon ?Request ? 7. ?IntrospecUon ?Response ?
Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? IntrospecMon ?API ?の課題点 ? !? アーキテクチャにも依るが、API ?Gateway ?以下でも ?Access ?Token ?をその まま通過させて、各 ?Service ?へのリクエストにした場合、厳密には ?Service ?ごとに ?Access ?Token ?の検証が必要であろう ? ?? 速度度重視の ?API ?に不不要なラウンドトリップが発?生する ? ?? つまり?大規模な ?Microservices ?に対して、採?用を躊躇わざるを得ない ? !? ?一つの解決策として ?API ?Gateway ?のみ ?Introspection ?Endpoint ?を使うと なりそう ? 16 ? Client ? API ?Gateway ? API ?(1) ? API ?(3) ? API ?(2) ? 1. ?API ?Request ? 2. ? ? 3. ? ? 4. ? ? 5. ? ?
Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? Access ?Token ?に ?JWT ?を使う ? !? Access ?Token ?は ?exp ?を迎える前に ?revoke ?さえされければ、 Resource ?Server ?でのアルゴリズム的な検証のみで良良い ? ?? また ?/_?ext/st ?は ?Scope ?Token ?(どんな権限があるか) ? 17 ? (注意) ?実際の ?Mobage ?Connect ?の ?Access ?Token ?と?一部フォーマットが異異なります ?
Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? 18 ? 以降降、構想段階のお話です ?
Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? Subscribe ?Endpoint ? !? Access ?Token ?が ?revoke ?された場合に ?Resource ?Server ?側に通知出来る 仕組みを作れば良良い ? ?? 他にも ?AuthZ ?Server ?のログインセッションが切切れたら ?session_?state ?を伝搬させるなど汎?用的な ?PubSub ?があったら便便利利だと思われる ? 19 ? AuthZ ?Server ? Token ?DB ? Client ? Resource ?Server ? Revoke ? Endpoint ? 1. ?Revoke ?Request ? 4. ?Revoke ?Response ? 2. ?Remove ?Token ? Subscribe ? Endpoint ? Revoke ?Token ? ? Subscriber ? Endpoint ? 3. ?Publish ?Revoke ?Event ? 事前に ?Subscribe ?Endpoint ?で ? Revoke ?Event ?を ?subscribe ?するための ? ? URL ?を登録しておく ? ?
Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? Revoke ?Event ?の伝搬 ? !? 上記のようなシステムを組む事で ?Revoke ?された ?Access ?Token ?の ?jti ?値などを伝搬させて、Revoke ?情報のみを各 ?Service ?に伝える ? ?? そうする事により、API ?は ?local ?通信で ?revoke ?された ?Access ? Token ?かどうかを確認出来るようになる ? 20 ? API ? Revoked ? Token ?DB ? (Redis) ? Service ? API ? Revoked ? Token ?DB ? (Redis) ? Service ? Revoked ? Token ?Publisher ? (Redis) ? Revoke ?Token ? Subscriber ? Endpoint ? AuthZ ?Server ? 1. ?Publish ?Token ? Revoked ?Event ? 2. ?Publish ?to ? channel ? Subscribe ? channel ? Lookup ?token ? (localhost) ? Lookup ?token ? (localhost) ?
Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? Revoke ?された ?Token ?情報の保持期間 ? !? 基本的には ?CSRF ?Token ?と同じコンセプトでやる ? !? つまり、revoke ?された ?jti ?だけ有効期限を迎えるまで、各 ?Service ?の ? Redis ?で持てば良良い ? ?? それ以降降は ?exp ??見見るだけで判断が付くため ? 21 ? Access ?Token ?(JWT) ?の有効期限 ? Cache ?に ?revoke ?された ? JWT ?の ?jU ?値を格納する ? 発?行行 ? Revoke ? iat ? exp ?
Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? Intent ?URI ?Scheme ?と ?Browser ?– ?NaMve ?App ?連携 ? Mobage ?Connect ?と ?Identity ?関連技術への取り組み ? 22 ?
Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? NaMve ?App ?に対する ?OAuth ?2/OIDC ?1.0 ?は魔物 ? !? 挙げれば切切りがない位、課題がある ? ?? 以下 ?AuthZ ?Server ?は ?Browser ?や別の ?App ?として開くと仮定 ? !? Native ?App ?にどのように ?access ?token ?を渡すか ? ?? Implicit ?or ?Authorization ?Code ? ?? Implicit ?でやると ?Custom ?URI ?の ?interception ?が出来てしまう ? (後述) ? ?? でも ?Native ?App ?は ?public ?client ?なので ?client ?secret ?は持てな いので ?Authorization ?Code ?は無理理では？ ? !? Native ?App ?が継続的に ?access ?token ?を得る為の仕組みをどう実現する か ? ?? Browser ?なら定期的に ?immediate ?login ?相当の ?implicit ?を続け れば良良い ? ?? AuthZ ?Server ?が ?Browser ?や ?Native ?App ?だと定期的にアプリ間 連携する?羽?目になる ? ? 23 ?
Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? Custom ?URI ?の中間者攻撃 ? !? 同じ ?Custom ?URI ?を持つ ?App ?が複数あったらどうなるか ? ?? 先勝ちになる ? ?? つまり、不不正な ?App ?に取られると ?Redirect ?URI ?に渡した情報が 盗まれる ? ? 24 ? hIp://tools.ie=.org/html/rfc7636 ?
Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? Custom ?URI ?の中間者攻撃への対策 ? !? Mobage ?Connect ?とそれを利利?用した ?Native ?SDK ?でも対策が?入っていま す ? ?? 但しセンシティブな話なので今?日はプロトコルの話はしません ? !? 今回話すのは、この中間者攻撃を成?立立させないようにする?比較的簡単 な対策についてお話します ? 25 ?
Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? Intent ?URI ?Scheme ?(Chrome) ? !? Chrome ?for ?Android ?の機能です ? ?? https://developer.chrome.com/multidevice/android/intents ? !? Android ?の ?Intent ?Filter ?の機能を詳細に指定して ?Native ?App ?を起動 させる事が出来ます ? 26 ? intent:{origin}{/path}{?queries*}#Intent ? ? ? ? ?{;package,action,category,component,scheme} ? ? ? ? ?;end ? intent:appId/callback? ? ? ? ? ?access_token=xyz123&state=abcd1234 ? ? ? ? ?#Intent;package=jp.or.openid; ? ? ? ? ?scheme=custom-?‐scheme;end ? URI ? Template ? URI ?
Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? Intent ?URI ?Scheme ?(Chrome) ? !? 上記のように ?Original ?URI ?を ?Intent ?URI ?Scheme ?形式に書き直します ? !? さらに?赤字の部分の ?package ?を明確に指定します ? ?? この ?package ?は ?AuthZ ?Server ?で事前に ?Redirect ?URI ?のホワイトリ スト登録時に?一緒に登録しておきます ? !? このようにする事で、不不正な ?package ?に対してそもそも ?AuthZ ?Response ?を返さないようにする事が出来ます ? 27 ? custom-?‐scheme:appId/callback? ? ? ? ? ?access_token=xyz123&state=abcd1234 ? intent:appId/callback? ? ? ? ? ?access_token=xyz123&state=abcd1234 ? ? ? ? ?#Intent;package=jp.or.openid; ? ? ? ? ?scheme=custom-?‐scheme;end ? Original ? URI ? Intent ? ? URI ?
Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? 諸注意 ? !? この仕組みは前述の通り ?Chrome ?for ?Android ?独?自の物なので、iOS ?の ? Mobile ?Safari ?では適?用出来ない ? ?? Android/iOS ?共に、もっと確かな別の仕組みの導?入が?大前提 ? 28 ?
Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? ご清聴ありがとうございました ? !? 時間があれば質疑応答 ? 29 ?

More Related Content

Mobage Connect と Identity 関連技術への取り組み - OpenID Summit Tokyo 2015

  • 1. Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? Mobage Connect と Identity 関連技術への 取り組み OpenID Summit 2015 November ?10, ?2015 ? Toru ?Yamaguchi ? Senior ?Architect ? ? Sub ?Business ?Unit ?Head ? Open ?Pla=orm ?Business ?Unit ? DeNA ?Co., ?Ltd. ? ?
  • 2. Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? 講演者紹介 ? !? ?氏名 ? ?? ?山?口 ?徹 ?(やまぐち ?とおる) ? !? HN ? ?? @zigorou ? !? 会社 ? ?? 株式会社ディー?エヌ?エー ? !? 部署 ? ?? オープンプラットフォーム事業本部 ? !? 役職 ? ?? 副事業本部??長 ?シニアアーキテクト ? !? 仕事 ? ?? Mobage ?やその他協業案件などにおける システム設計がメイン ? 2 ?
  • 3. Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? 本?日の概要 ? !? Mobage ?Connect ?(OpenID ?Server) ?の構築経験で、?工夫した点とし て以下の話をしていきます ? ?? CSRF ?Token ?への ?JWT ?の利利?用 ? ?? Access ?Token ?への ?JWT ?の利利?用と ?Microservices ? ?? Intent ?URI ?Scheme ?と ?Browser ?– ?Native ?App ?連携 ? !? 実践的な話につき ?JWT ?などの ?Identity ?技術の基本的な話はあまりし ません ? 3 ?
  • 4. Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? CSRF ?Token ?への ?JWT ?の利利?用 ? Mobage ?Connect ?と ?Identity ?関連技術への取り組み ? 4 ?
  • 5. Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? CSRF ?(Cross ?Site ?Request ?Forgery) ? !? CSRF ?とは上記のような攻撃?手法です ? ?? 例例えば、ログイン状態で所定の?手続きを経ないと本来出来ない?行行 為を強制的に?行行わせるといった事に使われます ? !? このような攻撃が成?立立させない為に?行行う対策の?一つとして ?CSRF ?Token ?の発?行行と検証があります ? 5 ? 事前の信頼関係 ? (セッションの確?立立) ? 1. ? ? 2. ? 3. ? 良良くある ?CSRF ?の例例として、 ? 1.? 何らかの悪意のある ?URL ?を踏ませる ? 2.? 正規の ?Web ?サーバーに対する不不正な リクエストを送出させるようなコンテ ンツを返却する ? 3.? ユーザーが意図しないうちに、不不正な リクエストが送信される ? 正規のWeb ?サーバー ? 悪意のある ?Web ?サーバー ?
  • 6. Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? 良良くある ?CSRF ?Token ?の仕組み ? !? Page ?A ?で ?Page ?Token ?を発?行行し、それを ?Cache ?Server ?(例例えば ? memcached ?や ?Redis ?のようなサーバー) ?に保存し、Page ?Token ?が 無いと ?Page ?B ?が?見見れないようにする ? ?? 消費するたびに ?Cache ?から削除すればワンタイム性が得られる ? 6 ? hIp://goo.gl/Wfvcz0 ?
  • 7. Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? 良良くある ?CSRF ?Token ?の課題点 ? !? 普段使う分には?大した問題ではないのですが、?大規模サービスだとあ ながちバカに出来ない課題があります ? ?? CSRF ?Token ?の発?行行?検証時に ?Cache ?Server ?とのラウンドトリ ップが必ず発?生してしまうこと ? ?? また ?CSRF ?Token ?の有効期限内、必ず ?Cache ?Server ?に ?CSRF ? Token ?が存在するようにしておかなければならない ? ?? Cache ?Server ?はしばしば ?eviction ?によってデータがロストする ? ?? どのページで発?行行された ?CSRF ?Token ?かをあまり検証していない ケースが多い ? ?? 不不正に ?CSRF ?Token ?が?入?手されると、クリティカルなページへのリクエ ストに利利?用され兼ねない ? !? そこで ?JWT ?を利利?用します！ ? 7 ?
  • 8. Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? CSRF ?Token ?の ?JWT ?Claims ?表現 ? !? /typ ?に ?csrf_?token ?と明記し、/_?ext ?に拡張データを?入れています ? ?? /_?ext/a ?は ?Page ?Token ?の発?行行ページの ?id ? ?? /_?ext/t ?は ?Tracking ?Cookie ?の ?Hash ?値 ? ?? /_?ext/p ?は ?hidden ?パラメータ等の埋め込み ?(改ざん防?止) ? 8 ? (注意) ?実際の ?Mobage ?Connect ?の ?CSRF ?Token ?と?一部フォーマットが異異なります ?
  • 9. Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? Cache ?サーバーは利利?用された際に使う ?(まだ構想段階) ? !? 基本的には ?JWT ?の ?iat ?+ ?有効期限に収まっているかをチェックする ? ?? アルゴリズムでの評価 ? !? 有効期限内の場合は ?Cache ?に ?invalidate ?情報が無い場合は未利利?用なので ? veri?ed ?とする ? ?? ある場合は利利?用済みなので ?not ?veri?ed ?とする ? 9 ? CSRF ?Token ?(JWT) ?の有効期限 ? (受け?入れページごとに定義) ? Cache ?に ?invalidate ?された ? JWT ?の ?jU ?値を格納する ? 発?行行 ? 検証 ? 有効期限 ?
  • 10. Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? Source ?AcMon ?と ?DesMnaMon ?AcMon ?(1) ? !? CSRF ?Token ?の ?/_?ext/a ?に埋め込まれた値 ?sa1 ?に対して ? ?? da1 ?では ?sa1 ?で発?行行された ?CSRF ?Token ?を受け付ける ? ?? da2, ?da3 ?では ?Reject ?される ? 10 ? Source ?(sa1) ? Source ?(sa2) ? Source ?(sa3) ? Dest ?(da1) ? accept ?(sa1) ? Dest ?(da2) ? accept ?(sa2) ? Dest ?(da3) ? accept ?(sa2, ?sa3) ? Reject ? Reject ?
  • 11. Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? Source ?AcMon ?と ?DesMnaMon ?AcMon ?(2) ? !? アクセス可能な関係値は上記のようになります ? ?? 受け?入れる ?Action ?のホワイトリストを ?WAF ?の ?Router ?設定に 記述しています ? 11 ? Source ?(sa1) ? Source ?(sa2) ? Source ?(sa3) ? Dest ?(da1) ? accept ?(sa1) ? Dest ?(da2) ? accept ?(sa2) ? Dest ?(da3) ? accept ?(sa2, ?sa3) ?
  • 12. Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? その他の拡張ポイント ? !? Tracking ?Cookie ?検証 ? ?? CSRF ?Token ?が仮に他者に奪われても ?Tracking ?Cookie ?のハッ シュ値が?一致しない限りは ?Reject ?されます ? !? 埋め込みパラメータの検証 ? ?? 特に ?submit ?前の ?form ?には ?input[@type=“hidden”] ?のような 埋め込みパラメータが良良く使われます ? ?? これらの値が改ざんされないように、JWT ?中に ?object ?として埋 め込み、実際に送信されたデータと?比較して、内容が改ざんされ ていれば ?Reject ?します ? 12 ?
  • 13. Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? Access ?Token ?への ?JWT ?の利利?用と ?Microservices ? Mobage ?Connect ?と ?Identity ?関連技術への取り組み ? 13 ?
  • 14. Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? Microservices ?と ?Access ?Token ?の相性が悪い件 ? !? Microservices ?はサービスごとに独?立立したインスタンスや ?DB ?を持ち、 API ?をインターフェースとして結合する ?Thin ?なやり?方 ? ?? そのようなケースで ?Token ?DB ?をどう参照するのか？ ? 14 ? AuthZ ?Server ? Token ?DB ? Client ? Resource ?Server ? Token ? ? Endpoint ? 1. ?Token ?Request ? 3. ?Token ?Response ? 2. ?Store ?Token ? 4. ?Request ?to ? ? Resource ?Server ? 異異なるネットワークにある ? Token ?DB ?をどう参照するか？ ?
  • 15. Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? OAuth ?2.0 ?Token ?IntrospecMon ?(RFC ?7662) ? !? Introspection ?Endpoint ?で ?Access ?Token ?の検証を ?AuthZ ?Server ? に依頼する事が出来る ? ?? これで?一応 ?Microservices ?にも対応出来るようになる ? 15 ? AuthZ ?Server ? Token ?DB ? Client ? Resource ?Server ? Token ? ? Endpoint ? 1. ?Token ?Request ? 3. ?Token ?Response ? 2. ?Store ?Token ? 6. ?Lookup ?Token ? 4. ?Request ?to ? ? Resource ?Server ? IntrospecUon ? Endpoint ? 5. ?IntrospecUon ?Request ? 7. ?IntrospecUon ?Response ?
  • 16. Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? IntrospecMon ?API ?の課題点 ? !? アーキテクチャにも依るが、API ?Gateway ?以下でも ?Access ?Token ?をその まま通過させて、各 ?Service ?へのリクエストにした場合、厳密には ?Service ?ごとに ?Access ?Token ?の検証が必要であろう ? ?? 速度度重視の ?API ?に不不要なラウンドトリップが発?生する ? ?? つまり?大規模な ?Microservices ?に対して、採?用を躊躇わざるを得ない ? !? ?一つの解決策として ?API ?Gateway ?のみ ?Introspection ?Endpoint ?を使うと なりそう ? 16 ? Client ? API ?Gateway ? API ?(1) ? API ?(3) ? API ?(2) ? 1. ?API ?Request ? 2. ? ? 3. ? ? 4. ? ? 5. ? ?
  • 17. Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? Access ?Token ?に ?JWT ?を使う ? !? Access ?Token ?は ?exp ?を迎える前に ?revoke ?さえされければ、 Resource ?Server ?でのアルゴリズム的な検証のみで良良い ? ?? また ?/_?ext/st ?は ?Scope ?Token ?(どんな権限があるか) ? 17 ? (注意) ?実際の ?Mobage ?Connect ?の ?Access ?Token ?と?一部フォーマットが異異なります ?
  • 18. Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? 18 ? 以降降、構想段階のお話です ?
  • 19. Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? Subscribe ?Endpoint ? !? Access ?Token ?が ?revoke ?された場合に ?Resource ?Server ?側に通知出来る 仕組みを作れば良良い ? ?? 他にも ?AuthZ ?Server ?のログインセッションが切切れたら ?session_?state ?を伝搬させるなど汎?用的な ?PubSub ?があったら便便利利だと思われる ? 19 ? AuthZ ?Server ? Token ?DB ? Client ? Resource ?Server ? Revoke ? Endpoint ? 1. ?Revoke ?Request ? 4. ?Revoke ?Response ? 2. ?Remove ?Token ? Subscribe ? Endpoint ? Revoke ?Token ? ? Subscriber ? Endpoint ? 3. ?Publish ?Revoke ?Event ? 事前に ?Subscribe ?Endpoint ?で ? Revoke ?Event ?を ?subscribe ?するための ? ? URL ?を登録しておく ? ?
  • 20. Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? Revoke ?Event ?の伝搬 ? !? 上記のようなシステムを組む事で ?Revoke ?された ?Access ?Token ?の ?jti ?値などを伝搬させて、Revoke ?情報のみを各 ?Service ?に伝える ? ?? そうする事により、API ?は ?local ?通信で ?revoke ?された ?Access ? Token ?かどうかを確認出来るようになる ? 20 ? API ? Revoked ? Token ?DB ? (Redis) ? Service ? API ? Revoked ? Token ?DB ? (Redis) ? Service ? Revoked ? Token ?Publisher ? (Redis) ? Revoke ?Token ? Subscriber ? Endpoint ? AuthZ ?Server ? 1. ?Publish ?Token ? Revoked ?Event ? 2. ?Publish ?to ? channel ? Subscribe ? channel ? Lookup ?token ? (localhost) ? Lookup ?token ? (localhost) ?
  • 21. Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? Revoke ?された ?Token ?情報の保持期間 ? !? 基本的には ?CSRF ?Token ?と同じコンセプトでやる ? !? つまり、revoke ?された ?jti ?だけ有効期限を迎えるまで、各 ?Service ?の ? Redis ?で持てば良良い ? ?? それ以降降は ?exp ??見見るだけで判断が付くため ? 21 ? Access ?Token ?(JWT) ?の有効期限 ? Cache ?に ?revoke ?された ? JWT ?の ?jU ?値を格納する ? 発?行行 ? Revoke ? iat ? exp ?
  • 22. Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? Intent ?URI ?Scheme ?と ?Browser ?– ?NaMve ?App ?連携 ? Mobage ?Connect ?と ?Identity ?関連技術への取り組み ? 22 ?
  • 23. Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? NaMve ?App ?に対する ?OAuth ?2/OIDC ?1.0 ?は魔物 ? !? 挙げれば切切りがない位、課題がある ? ?? 以下 ?AuthZ ?Server ?は ?Browser ?や別の ?App ?として開くと仮定 ? !? Native ?App ?にどのように ?access ?token ?を渡すか ? ?? Implicit ?or ?Authorization ?Code ? ?? Implicit ?でやると ?Custom ?URI ?の ?interception ?が出来てしまう ? (後述) ? ?? でも ?Native ?App ?は ?public ?client ?なので ?client ?secret ?は持てな いので ?Authorization ?Code ?は無理理では？ ? !? Native ?App ?が継続的に ?access ?token ?を得る為の仕組みをどう実現する か ? ?? Browser ?なら定期的に ?immediate ?login ?相当の ?implicit ?を続け れば良良い ? ?? AuthZ ?Server ?が ?Browser ?や ?Native ?App ?だと定期的にアプリ間 連携する?羽?目になる ? ? 23 ?
  • 24. Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? Custom ?URI ?の中間者攻撃 ? !? 同じ ?Custom ?URI ?を持つ ?App ?が複数あったらどうなるか ? ?? 先勝ちになる ? ?? つまり、不不正な ?App ?に取られると ?Redirect ?URI ?に渡した情報が 盗まれる ? ? 24 ? hIp://tools.ie=.org/html/rfc7636 ?
  • 25. Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? Custom ?URI ?の中間者攻撃への対策 ? !? Mobage ?Connect ?とそれを利利?用した ?Native ?SDK ?でも対策が?入っていま す ? ?? 但しセンシティブな話なので今?日はプロトコルの話はしません ? !? 今回話すのは、この中間者攻撃を成?立立させないようにする?比較的簡単 な対策についてお話します ? 25 ?
  • 26. Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? Intent ?URI ?Scheme ?(Chrome) ? !? Chrome ?for ?Android ?の機能です ? ?? https://developer.chrome.com/multidevice/android/intents ? !? Android ?の ?Intent ?Filter ?の機能を詳細に指定して ?Native ?App ?を起動 させる事が出来ます ? 26 ? intent:{origin}{/path}{?queries*}#Intent ? ? ? ? ?{;package,action,category,component,scheme} ? ? ? ? ?;end ? intent:appId/callback? ? ? ? ? ?access_token=xyz123&state=abcd1234 ? ? ? ? ?#Intent;package=jp.or.openid; ? ? ? ? ?scheme=custom-?‐scheme;end ? URI ? Template ? URI ?
  • 27. Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? Intent ?URI ?Scheme ?(Chrome) ? !? 上記のように ?Original ?URI ?を ?Intent ?URI ?Scheme ?形式に書き直します ? !? さらに?赤字の部分の ?package ?を明確に指定します ? ?? この ?package ?は ?AuthZ ?Server ?で事前に ?Redirect ?URI ?のホワイトリ スト登録時に?一緒に登録しておきます ? !? このようにする事で、不不正な ?package ?に対してそもそも ?AuthZ ?Response ?を返さないようにする事が出来ます ? 27 ? custom-?‐scheme:appId/callback? ? ? ? ? ?access_token=xyz123&state=abcd1234 ? intent:appId/callback? ? ? ? ? ?access_token=xyz123&state=abcd1234 ? ? ? ? ?#Intent;package=jp.or.openid; ? ? ? ? ?scheme=custom-?‐scheme;end ? Original ? URI ? Intent ? ? URI ?
  • 28. Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? 諸注意 ? !? この仕組みは前述の通り ?Chrome ?for ?Android ?独?自の物なので、iOS ?の ? Mobile ?Safari ?では適?用出来ない ? ?? Android/iOS ?共に、もっと確かな別の仕組みの導?入が?大前提 ? 28 ?
  • 29. Copyright ?(C) ?DeNA ?Co.,Ltd. ?All ?Rights ?Reserved. ? ご清聴ありがとうございました ? !? 時間があれば質疑応答 ? 29 ?