サーバーレスAPIのセキュリティ－API認可の基本を押さえ、AIエージェント時代に備える（CNS315）
はじめに
みなさんこんにちは、クラウド事業本部の浅野です。
AWS Summit Japan 2026に参加してきました。本記事では、セッション「サーバーレスAPIのセキュリティ－API認可の基本を押さえ、AIエージェント時代に備える－」のレポートをお届けします。
特に、OAuthの認可パターンについて、人を介在する「認可コードフロー」とマシン間（M2M）の「クライアントクレデンシャルフロー」をわかりやすく整理・図解してくれていた非常に有意義なセッションでした。
セッション資料は以下から参照できます。
セッションの概要
- タイトル: サーバーレスAPIのセキュリティ－API認可の基本を押さえ、AIエージェント時代に備える－
- セッション番号: CNS315
- 登壇者: 渡辺 紘久 氏 / アマゾン ウェブサービス ジャパン合同会社
このセッションでは、フィットネスアプリを題材にサーバーレスAPIのセキュリティ対策を基礎から解説し、OAuth2/OIDCによるAPI認可の仕組みを丁寧に整理した上で、AIエージェント時代の認可にどうつながるかが語られました。
| # | アジェンダ |
|---|---|
| 1 | 題材: フィットネスアプリ |
| 2 | APIセキュリティの基礎 |
| 3 | アイデンティティ(ID)を意識したAPI認可 |
| 4 | AIエージェントの認可 - はじめの一歩 |
| 5 | まとめ |
サーバーレスアプリケーションの全体像
セッションではフィットネスアプリを題材に、サーバーレスAPIのセキュリティについて紹介されていました。
Fitness Webアプリケーションから複数のAPI（Activities API、Routes API、Socials API、Support API）を呼び出し、それぞれAPI Gateway → Lambda → DynamoDBという構成です。この構成を前提に、セキュリティ対策を層ごとに解説していく流れでした。
APIセキュリティの基本
APIセキュリティの基本として、「IAMを土台にしたセキュアなAPI構築」と「開発スピードを止めない自動化と守りの多層防御」の2つの観点で説明がありました。
IAMではコントロールプレーン（CloudFormation等によるデプロイ）とデータプレーン（API実行時）それぞれでの最小権限の適用、Amazon InspectorによるLambda関数の脆弱性スキャン、Amazon GuardDutyによるLambda実行時の脅威検出、AWS WAFによるAPIエンドポイントの保護（IPベースの制御、レートベースルール、OWASP Top 10を踏まえたマネージドルール）、API Gatewayのリクエストバリデーションによる入力検証など、多層防御の全体像がさらっと紹介されていました。
IDベースのAPI認可: OAuth2とOIDC
ここからがセッションの核心部分です。まず「APIにおける認可ポイントの整理」として、リクエストの流れが示されました。
ユーザー → Webブラウザ → Webアプリケーション → API Gateway → Lambdaという流れの中で、認可ポイントは大きく2つに分かれます。
- ユーザー認証と認可（左側）: ユーザーがWebアプリケーションにアクセスする際の認証・認可
- リソースポリシーと実行ロール（右側）: API GatewayやLambdaにおけるIAMベースのアクセス制御
OAuth2は「認可」、OIDCは「認証」
登壇者の方が繰り返し強調されていたのが、OAuth2は「認可」のプロトコルであり、OIDC（OpenID Connect）は「認証」のプロトコルであるという点です。
- OAuth2: 「このアプリケーションに、あなたのデータへのアクセスを許可しますか？」という認可の仕組み
- OIDC: OAuth2の上に構築された認証の仕組みで、「あなたは誰ですか？」を証明する
この区別は一見シンプルですが、後半のAIエージェントの認可を理解する上で非常に重要な土台になります。
OAuth2の登場人物
OAuth2には4つのアクター（登場人物）が定義されています。フィットネスアプリに当てはめると以下のようになります。
| アクター | 役割 | フィットネスアプリでの例 |
|---|---|---|
| リソースオーナー | データの所有者 | ユーザー |
| ユーザーエージェント | ユーザーの操作手段 | Webブラウザ |
| クライアント | リソースへのアクセスを要求するアプリ | Webアプリケーション |
| 認可サーバー | トークンを発行する | Amazon Cognito |
| リソースサーバー | 保護されたリソースを提供する | API Gateway |
関連するクレデンシャル
OAuth2で使用されるクレデンシャルとして、以下の2つが紹介されていました。
- クライアントID: 公開可能な情報で、アプリケーションの識別用
- クライアントシークレット: 秘密情報で、アプリケーションの認証用
※ Confidential Client（サーバーサイドアプリなど、クライアントシークレットを安全に保管できるクライアント）を前提とした説明でした。
関連するトークン
トークンの整理も非常にわかりやすかったです。
| トークン | 有効期間 | 用途 | プロトコル |
|---|---|---|---|
| アクセストークン | 短期間 | 保護されたリソースへのアクセス時に提示し、許可された操作範囲（スコープ）を定義 | OAuth2 |
| リフレッシュトークン | 長期間 | ユーザーの再ログインなしに、期限切れのアクセストークンを自動的に更新 | OAuth2 |
| IDトークン | 短期間 | ユーザーのID情報（名前・メール等）を含み、リクエスターが「誰か」を示す認証の証明として使用 | OIDC |
アクセストークンとリフレッシュトークンはOAuth2の領域、IDトークンはOIDCの領域と明確に分類されていた点がポイントです。
OAuth2グラントタイプ
OAuth2のグラントタイプ（認可の方法）として、以下の2つが繰り返し説明されていました。
| グラントタイプ | アクセス方式 | ユースケース |
|---|---|---|
| 認可コードフロー | ユーザーを代理してアクセス（人が介在） | Webアプリケーションからユーザーの代わりにAPIを呼ぶ |
| クライアントクレデンシャルフロー | アプリ自身としてアクセス（マシン間/M2M） | バッチ処理やサービス間連携など、人を介さないアクセス |
この2つのグラントタイプの違いを何度も強調されていたのが印象的でした。セッションでは認可コードフロー側、クライアントクレデンシャルフロー側それぞれにフォーカスしながら、フローの詳細が説明されていきます。
認可コードフロー: ユーザーを代理してアクセス（人が介在）
フェーズ1: 認可コード生成
認可コードフローのフェーズ1では、以下の流れで認可コードが生成されます。
- ユーザーがアプリにアクセス
- Webアプリケーション（クライアント）がクライアントID付きで認可サーバー（Amazon Cognito）にリダイレクト
- ユーザーがログイン画面で認証
- 認可コードが生成される
- 認可コード付きでWebアプリケーションにリダイレクト
フェーズ2: トークン生成と使用
フェーズ2では、生成された認可コードを使ってトークンを取得し、APIにアクセスします。
- Webアプリケーション（クライアント）が認可コードを受信
- クライアントID、クライアントシークレット、認可コードを認可サーバー（Amazon Cognito）に送信し、トークンと交換
- Bearerトークンによる保護リソースへのリクエスト
- API Gateway（リソースサーバー）がBearerトークンの検証に使う公開鍵を認可サーバーから取得
- トークン検証成功後、Lambdaでビジネスロジックを実行
デプロイ時にクライアントIDとクライアントシークレットをWebアプリケーションに配置しておく必要がある点も説明されていました。
クライアントクレデンシャルフロー: アプリ自身としてアクセス（マシン間/M2M）
クライアントクレデンシャルフローは、認可コードフローと比べて非常にシンプルです。人が介在しないため、ログイン画面も認可コードの生成も不要です。
- バッチアプリケーション（クライアント）がクライアントIDとクライアントシークレットを認可サーバー（Amazon Cognito）に送信し、トークンと交換
- Bearerトークンによる保護リソースへのリクエスト
- API Gateway（リソースサーバー）がBearerトークンの検証に使う公開鍵を取得
認可コードフローとの大きな違いは、ユーザーの認証が不要で、クライアント自身のクレデンシャルだけでトークンを取得できる点です。バッチ処理やサービス間連携など、人を介さないマシン間通信に適しています。
ビジネスロジックでのトークン活用
API GatewayからLambdaに渡されるリクエストコンテキストには、トークンから取得したクレーム情報が含まれます。sub（ユーザーID）、username、cognito:groups（所属グループ）、scope（許可された操作範囲）などが確認でき、Lambda側のビジネスロジックでこれらの情報を使ったきめ細やかな認可判断が可能です。
きめ細やかな認可: Amazon Verified Permissions
OAuth2による認可だけでは賄えない、ユーザーごとのきめ細やかなアクセス制御が必要なケースも紹介されていました。たとえば「このユーザーは自分のアクティビティデータのみ閲覧可能」「管理者はすべてのデータにアクセス可能」といった制御です。
AWSではこのような認可ポリシーの管理にAmazon Verified Permissionsが利用できます。フローは以下の通りです。
- ユーザーがアイデンティティプロバイダー（認可サーバー）で認証
- Bearerトークンによる保護されたリソースへのリクエスト
- API Gateway（リソースサーバー）がBearerトークンが有効であることを確認
- LambdaオーソライザーがVerified Permissionsにポリシーを評価させる
- 認可が通ればバックエンドを呼び出し
Verified PermissionsではCedarというポリシー言語を使用し、認可ロジックをアプリケーションコードから分離して管理できます。認可ポリシーをアプリケーション側に直接記載することも可能ですが、Verified Permissionsを使うことでポリシーの一元管理やテストが容易になります。
AIエージェントの認可: OAuth2が土台になる
セッションの最後に、これまで説明してきたOAuth2/OIDCの考え方がAIエージェント時代にどうつながるかが語られました。登壇者の方はこの点を強く強調されていました。
まず前提として、これまで説明してきたフィットネスアプリのAPIを、今度はAIエージェントから利用するシナリオが示されました。アーキテクチャは同じAPI Gateway → Lambda → DynamoDBの構成で、呼び出し元がWebアプリケーションからエージェントに変わります。
Tool CallingからMCPへ
AIエージェントがAPIを呼び出す仕組みとして、まずTool Calling（エージェントが各APIを直接呼び出す）が紹介されました。しかしこの方式では、ツールごとに接続方法がバラバラになるという課題があります。
これを標準化したのがMCP（Model Context Protocol）です。MCPクライアントとMCPサーバーを介してAPIに接続することで、接続方式が統一されます。
エージェントでのOAuth2適用
MCPの仕組みにOAuth2を適用すると、Fitnessエージェント内のActivitiesツールがMCPクライアントを介し、MCPサーバー経由でActivities APIに接続します。ここで重要なのは、これまで学んできたOAuth2のフローがそのまま使われるという点です。
AIエージェントにOAuth2を適用する場合、ユーザーの認証には認可コードフロー、MCPクライアント-MCPサーバー間やMCPサーバー-API間の通信にはクライアントクレデンシャルフローが使われます。
しかしここに課題があります。クライアントクレデンシャルフローだけではユーザーIDが伝播されないのです。エージェントがユーザーの代わりにAPIを呼び出す際、「誰のリクエストなのか」という情報がM2M通信の中で失われてしまいます。スライドにも「※ユーザーのID伝搬は別途必要→トークン交換で解決」と明記されていました。自前でToken Exchangeを実装するのは容易ではありません。
マネージドサービスによる解決: Amazon Bedrock AgentCore
この課題をマネージドに解決するのがAmazon Bedrock AgentCoreです。AgentCoreは、AIエージェントを安全に大規模にデプロイ・運用するための基盤サービス群で、Runtime、Gateway、Identity、Memory、Observabilityなどの構成要素から成り立っています。
特にAgentCore Identityは、エージェントの認証・認可とクレデンシャル管理を担うコンポーネントです。
- インバウンド認証: ユーザー → アプリケーション → エージェントへのアクセスをIAM/OAuthで認証
- アウトバウンド認証: エージェントから各リソースへのアクセスをIAM（AWSリソース向け）やOAuth（AgentCore Gateway・外部リソース向け）で認証
つまり、先ほど説明したOAuth2のフローやトークンエクスチェンジの仕組みを、AgentCoreが裏側でマネージドに処理してくれるということです。
まとめ
本セッションのポイントを整理します。
- OAuth2は「認可」、OIDCは「認証」: この区別がすべての土台。OAuth2でアクセス権限を制御し、OIDCで「誰か」を証明する
- 2つのグラントタイプを理解する: 人が介在する「認可コードフロー」と、マシン間の「クライアントクレデンシャルフロー」。ユースケースに応じて使い分ける
- トークンの役割を整理する: アクセストークン（短期間・スコープ定義）、リフレッシュトークン（長期間・自動更新）、IDトークン（認証の証明）
- OAuth2だけでは賄えないきめ細やかな認可にはVerified Permissions: ポリシーをアプリから分離し、Cedar言語で管理
- AIエージェントの認可もOAuth2/OIDCが土台: Tool Calling → MCP → OAuth2適用という流れで、従来のAPI認可の知識がそのまま活きる
- マシン間通信でのユーザーID伝播が課題: クライアントクレデンシャルフローだけではユーザー情報が失われるため、Token Exchangeが必要
- Amazon Bedrock AgentCoreでマネージドに解決: AgentCore Identityがインバウンド・アウトバウンドの認証・認可を一元管理
- 多層防御、最小権限、自動化、サービス統合: サーバーレスAPIセキュリティの4つの原則
最後に
セッション全体を通して、人が介在する場合は認可コードフロー、介在しない日次のバッチ処理やサービス間連携などはクライアントクレデンシャルフロー、というように具体的な例を交えながら説明してくれたので非常にわかりやすかったです。
OAuth2のフローやトークンの役割について、自分自身やんわりとした理解に留まっていた部分があったのですが、登場人物・クレデンシャル・トークン・フローをシチュエーションごとに整理して図解してくれたおかげで、解像度がかなり上がりました。
AIエージェントがMCPを介してAPIを呼び出す際の認可フローは新しい概念に見えて、結局はOAuth2/OIDCの基本に立ち返るという構成が腹落ちしやすく、今後お客様にAPI認可の話をする際にもこのセッションの整理の仕方を参考にしたいと思います。
以上、AWS Summit Japan 2026のセッション「サーバーレスAPIのセキュリティ」のレポートでした。
