目的地
「OpenID Connect入門」に至る道筋
この本にたどり着くために、先に読んでおきたい本を依存関係から逆算しました。基礎から順に並んでいます。
ここまでの道筋（7冊）
なぜ先に読むのか: TCP/IP と HTTP の動作原理を理解すると、その上に成り立つ REST API の設計判断が「なぜそうするか」まで腑に落ちる。Web API The Good Parts は HTTP の意味論を踏まえた URI・メソッド・ステータスコードの実践的な設計指針を与える。
なぜ先に読むのか: 脆弱性対策の全体像を掴んだら、その多くが依拠する暗号の土台へ降りる。ハッシュ・署名・公開鍵暗号の論理を理解しておくと、TLSやトークン検証を「魔法」ではなく原理で扱えるようになる。
なぜ先に読むのか: 署名と公開鍵暗号の土台があって初めて、トークンベースの認可を正しく理解できる。OAuth 2.0は権限委譲のデファクトであり、その各グラントとフローを原理から学ぶ。
なぜ先に読むのか: 新規登録からログアウト、ID連携までID管理の全体像を平易な言葉で押さえると、OAuth 2.0 と OIDC のプロトコル仕様というより専門的で細かい実装の話に進む土台ができる。はじめてのデジタルアイデンティティで身元確認・当人認証・セッション管理の関係を整理しておくと、OpenID Connect入門が扱う認可コードフローやトークン検証の位置づけが掴みやすくなる。
なぜ先に読むのか: OAuth 2.0は本来「認可」のプロトコルで、それを誤用した擬似認証は脆弱性の温床になる。本人確認を標準化したOIDCへ進むことで、IDトークン検証を含む正しい認証の組み立てが分かる。
なぜ先に読むのか: Web の基盤技術を一通り押さえたら、それを使って「良い API」をどう設計するかという実践へ進む。Web API The Good Parts は HTTP の意味論に忠実な URI 設計・エラー表現・バージョニングの定石を与え、原理を設計判断に変換する。
なぜ先に読むのか: API の設計ができるようになったら、その API を「誰がどの権限で叩けるか」を制御する認証・認可の層が要る。OpenID Connect は OAuth 2.0 を土台に本人確認を標準化した仕組みで、トークンベースのアクセス制御を API に組み込む定石を与える。