← AWSサービスの内部原理 コース
131. API Gatewayはトークンを2つの流儀で検証する — CognitoオーソライザーとJWTオーソライザー
API Gateway編では「オーソライザーがリクエストを通すか弾くか」までを見ましたが、今回はその一段深く、Authorizationヘッダーに載ったトークンの中身を、いったい誰が・どう検証しているのかを図で追っていきます。
① 全体像 — 2製品・2オーソライザーの地図
クライアントAuthorizationヘッダーにトークン
REST APICognitoオーソライザー
COGNITO_USER_POOLSHTTP APIJWTオーソライザー
Cognito専用検証ユーザープール専用
汎用検証jwks_uriを持つ発行元なら何でも
Cognito専用の統合
OIDC/OAuth汎用統合
同じ「トークンを検証する」でも、REST API+CognitoはCognito専用、HTTP API+JWTは発行元を問わない汎用 — この違いが今回の全ての土台です。
② REST API + Cognitoオーソライザー
クライアント
Authorizationヘッダーに載せる
identity/access tokenトークン取得
検証へ
API Gatewayメソッド呼び出しLambdaオーソライザーを介さない
COGNITO_USER_POOLS検証API Gateway自身が真正性を検証
トークン有効通す(バックエンドへ)
無効/欠落認可エラー(credentialsがauthorizeされない)
Cognitoオーソライザーの本質は「API Gatewayとユーザープールの直結」。開発者が検証コードを書かず、製品側がトークンの真正性を判定します。
③ IDトークン vs アクセストークン
identity token認可の軸: identity claims
誰か=サインインしたユーザーの属性access token認可の軸: custom scopes
どの保護リソースへのアクセス権かこのユーザーだから通す
このスコープを持つから通す
IDトークンは「誰か(identity claims)」、アクセストークンは「何をしてよいか(custom scopes)」。認可の判断材料が違うので、用途で選びます。
④ HTTP API + JWTオーソライザーの4段階
identitySourceから取得トークン単体 or "Bearer "前置
②
トークンをデコード
③
アルゴリズム・署名検証発行元のjwks_uriの公開鍵を使用
RSA系のみ・最大2時間キャッシュ④
claims検証次のセクションで詳細
全て通過claimsをバックエンドへ
どれか失敗API Gatewayが拒否
JWKS検証レッスンで学んだ手順が、そのままAPI Gatewayの中に実装されている「答え合わせ」の回。RSA限定・公開鍵2時間キャッシュという具体値まで公式に明記されています。
⑤ 公開鍵2時間キャッシュと鍵ローテーション
時刻t0公開鍵を取得・キャッシュ開始
鍵ローテーション時は
キャッシュ期間中発行元が鍵を差し替えても旧鍵を保持しうる
猶予期間を設ける新旧両方の鍵を有効にする(公式ベストプラクティス)
旧鍵署名トークンも検証通過キャッシュ失効し新鍵を引くまでの間
「JWKSはキャッシュされる」の具体値=最大2時間。この遅延があるからこそ、鍵ローテーション時は新旧を重ねる猶予期間が要る、という因果です。
⑥ claims検証の突き合わせ
kid→ jwks_uriの署名鍵と一致
iss→ 設定Issuerと一致
aud優先/client_id両方あればaudを評価
exp/nbf/iat現在時刻(UTC)と前後関係を照合
scope または scp設定スコープを1つ以上含むか
全て通過認可成功
どれか失敗拒否
claims検証とは「トークンの主張」と「オーソライザーの設定」の突き合わせの束。特にaudとclient_idは、両方あればaudを優先という優先順位まで公式に決まっています。
⑦ 締め — JWTオーソライザーがHTTP API専用の理由
REST API + Cognitoユーザープールに直結
Cognito専用の統合HTTP API + JWTjwks_uriを持つ発行元なら何でも
発行元を問わない汎用の統合標準仕様だけで完結OIDC/OAuth・JWKS・RSA署名
「JWTオーソライザーだけはHTTP API専用」という既習事実は、特定製品に縛られず標準仕様だけで検証を完結させる設計が理由だった、という答え合わせです。