目的地
「セキュアAPI」に至る道筋
この本にたどり着くために、先に読んでおきたい本を依存関係から逆算しました。基礎から順に並んでいます。
ここまでの道筋（8冊）
なぜ先に読むのか: 署名と公開鍵暗号の土台があって初めて、トークンベースの認可を正しく理解できる。OAuth 2.0は権限委譲のデファクトであり、その各グラントとフローを原理から学ぶ。
なぜ先に読むのか: 新規登録からログアウト、ID連携までID管理の全体像を平易な言葉で押さえると、OAuth 2.0 と OIDC のプロトコル仕様というより専門的で細かい実装の話に進む土台ができる。はじめてのデジタルアイデンティティで身元確認・当人認証・セッション管理の関係を整理しておくと、OpenID Connect入門が扱う認可コードフローやトークン検証の位置づけが掴みやすくなる。
なぜ先に読むのか: TCP/IP と HTTP の動作原理を理解すると、その上に成り立つ REST API の設計判断が「なぜそうするか」まで腑に落ちる。Web API The Good Parts は HTTP の意味論を踏まえた URI・メソッド・ステータスコードの実践的な設計指針を与える。
なぜ先に読むのか: OAuth 2.0は本来「認可」のプロトコルで、それを誤用した擬似認証は脆弱性の温床になる。本人確認を標準化したOIDCへ進むことで、IDトークン検証を含む正しい認証の組み立てが分かる。
なぜ先に読むのか: Web の基盤技術を一通り押さえたら、それを使って「良い API」をどう設計するかという実践へ進む。Web API The Good Parts は HTTP の意味論に忠実な URI 設計・エラー表現・バージョニングの定石を与え、原理を設計判断に変換する。
なぜ先に読むのか: REST の基本的な設計指針を身につけたら、API を「契約」として記述・共有する実践へ進む。The Design of Web APIs は OpenAPI による仕様駆動の設計プロセスを示し、場当たりでない一貫した API を組織で作るための型を与える。
なぜ先に読むのか: OpenAPI による契約設計やページネーション・バージョニングといったAPI設計の実践を押さえると、その設計にセキュリティをどう組み込むかという次の課題が見えてくる。セキュアAPIはシフトレフトの考え方のもと、設計段階から認証・認可の脆弱性やAPI設定管理上のリスクに向き合う視点を積み上げる。
なぜ先に読むのか: OIDCの認可コードフローやJWT検証を実装レベルで理解したら、視野をAPI全体の設計へ広げる。本書は認証・認可に起因する脆弱性だけでなく、API設定管理のリスク、金融グレードAPIの要件、オブザーバビリティやテストまで、設計段階からセキュリティを組み込む視点を与える。