1. 概要
モバイルアプリ開発において、ブラックボックス化しやすいリクエストがサーバーに到達するまでの技術スタックを以下のように体系化します。
2. コンポーネント定義と役割
各要素がどのレイヤーで何を担保しているかを整理します。
| 分類 | コンポーネント | 役割・機能 |
|---|---|---|
| Identity | Ory Kratos | ユーザーの識別情報（ID/Pass等）とログインセッションの状態保持を担当します。 |
| Protocol | Ory Hydra | OAuth 2.0 / OpenID Connect に準拠したトークンの発行・管理を担当します。 |
| Gateway | Kong | システム外部からのリクエストの検閲、ルーティング、共通処理の集約を担当します。 |
| Sidecar | Envoy | サービス間通信の制御（リトライ、タイムアウト、認可の検証代行）を担当します。 |
| Delivery | CDN | エッジサーバーでのコンテンツキャッシュおよび低遅延配信を担当します。 |
3. リクエスト・ライフサイクルのシーケンス
モバイルアプリからリクエストが送出され、レスポンスが返却されるまでの論理的フローです。
3.1 補足：フェーズ別の要点
-
認可フェーズ: モバイルアプリはソースコード解析が可能な「パブリッククライアント」であるため、クライアントシークレットを保持せず、PKCEによって認可コードの横取り攻撃を防御します。
-
リクエストフェーズ: 玄関口である Kong が Hydra と連携し、不正なトークンを早い段階で遮断することで、後続のコンピューティングリソースを保護します。
-
レスポンスフェーズ: バックエンドアプリが返却する
-
Cache-Control:
private等のヘッダーに基づき、CDN が「特定のユーザー向けデータ」を誤って他者に配信しないよう制御します。
4. 体系的理解における重要事項
4.1 信頼の連鎖
システムは、最前段の Kratos による「人間」の認証を起点としています。
それを Hydra が「トークン」という抽象化された証明書に変換することで、
後続の Kong や Envoy が個別のユーザー情報を都度参照せずに（ステートレスに）正当性を判断できる構造になっています。
それぞれのコンポーネントが各々の責務を全うし、
スコープを越えた働きかけをしない、
といった単一責任に基づく信頼の連鎖に基づいています。
4.2 プロキシの分類
-
フォワードプロキシ: クライアント側に位置します。通信の秘匿化、フィルタリング、開発時のデバッグ（Proxyman等）に使用されます。
-
リバースプロキシ: サーバー側に位置します。負荷分散、セキュリティ、SSL終端、構成の隠蔽（Kong, Nginx, CDN等）に使用されます。
4.3 キャッシュとセキュリティの整合性
CDNを利用する場合、認証情報の有無によってキャッシュの可否を厳密に制御する必要があります。
誤ったキャッシュ設定は、個人情報漏洩のリスクを伴うため、インフラレベルでの設計が不可欠です。
参考