こんにちは、SCSK林です！
私が担当した某プロジェクトで、社内向けWebアプリケーションとしてS3静的ホスティングによるSPA（Single Page Application）、およびALBとLambdaによるサーバーレスバックエンドを採用しました。技術的にはモダンで、運用コストを極小化できる構成です。
しかし、ここで大きな技術的課題としてあったのが「認証機能（Authentication）」です。 そのプロジェクトでは全社的なID管理基盤（IdP）として、Microsoft Entra ID（旧Azure AD）が導入されていました。セキュリティガバナンスの観点から、AWS上に独自のIDストア（データベース）を構築することはよろしくなく、Entra IDのアカウントでログインすることが要件としてありました。
本記事では、この要件に対し Entra ID と Cognito をどう連携させセキュアなWebアプリケーションを構築したかをご紹介します。
アーキテクチャの全体像と設計思想
まず、今回構築した認証・認可フローの全体像を示します。
- フロントエンド (SPA) : Amazon S3 (静的ホスティング)
- Auth Broker (認証ブローカー) : Amazon Cognito User Pool
- Identity Provider (IdP) : Microsoft Entra ID (SAML 2.0連携)
- バックエンド : Elastic Load Balancing + AWS Lambda
この構成における最大のポイントは、「認証の責務をCognitoに集約し、アプリケーション（フロント・バックエンド）からEntra ID固有の実装を排除したこと」です。
また、通常、SPAからバックエンドAPIを呼び出す際、トークンの有効性検証（JWTの署名チェックや期限確認）をLambda内のコードで行う必要があります。しかし、ALBの「認証（Authenticate）」アクションを利用すれば、ALB自体がCognitoと直接対話し、検証済みのユーザー情報のみをLambdaにフォワードしてくれます。
これにより、Lambdaから認証の複雑性を完全に排除し、「インフラレイヤーでセキュリティを担保する」という、より堅牢な設計を実現しました。
技術的ポイント①：SAML 2.0 と OIDC
このアーキテクチャのポイントとなるのが、Cognitoによるプロトコル変換と、ALBによる認証プロセスの自動化です。
プロトコルの抽象化（SAML to OIDC）
Entra ID側では、Cognito を SAML 2.0のサービスプロバイダー（SP）として登録します。ユーザーがログインを試みると、Entra IDのサインイン画面へリダイレクトされ、認証成功後にSAMLアサーション（XML）を持ってCognitoに戻ります。
CognitoはこのSAMLアサーションを解析し、AWS内で扱いやすいJWT（ID Token / Access Token）を発行します。これにより、フロントエンドエンジニアはEntra ID固有の複雑なSAML仕様を意識せず、モダンなOIDCプロトコルに基づいて開発を進めることができます。これはフロントエンド側の開発としては認証機能を抽象化し実装を容易としました。
ALBリスナールールによるゼロトラストな実装
ALBの設定では、特定のパス（/api/* など）へのリクエストに対し、Cognito User Poolによる認証を強制するルールを定義しました。
ユーザーが未認証でAPIにアクセスしようとすると、ALBが自動的にCognitoのログインエンドポイントへリダイレクトさせます。認証が完了すると、ALBはCognitoから取得したトークンを検証し、署名付きヘッダーにユーザー情報を格納してLambdaへ渡します。
この仕組みのよい点は、Lambda側でトークンの検証ロジックを1行も書かなくて済む点です。Lambdaは、このヘッダーが存在すること自体が「認証済み」の証拠として扱えるため、コードの簡素化と脆弱性排除を同時に達成できました。
技術的ポイント②：AWS Amplifyによるフロントエンド統合
フロントエンド（SPA）には AWS Amplify (JavaScript Library) を採用しました。
今回の構成では、認証の主体がCognito（かつその背後にEntra ID）であるため、AmplifyのAuthライブラリを利用することで、複雑なリダイレクト処理やセッション管理を極めて簡潔に記述できました。
技術的ポイント③：セキュリティと認可 – Entra IDグループとの連動
本システムは社内ツールであるため、利用可能なユーザーを特定のメンバーに限定する必要がありました。
グループベースの認可制御
全社員が持つEntra IDのアカウントを使いつつ、アクセス制限を行うために、Entra ID側の「セキュリティグループ」を活用しました。
- Entra ID側 : 特定のグループに属するユーザーのみに、本アプリケーションへのSAMLアサーションを発行するよう設定。
- Cognito側 : 受信したSAMLクレームをユーザープールの属性にマッピング。
- ALB / Lambda側 : ALBから渡される署名付きヘッダー内のグループ情報を、Lambda側でチェック。
これにより、IDのライフサイクル管理（入社・退社・異動による権限変更）はすべてEntra ID側に集約され、AWS側での二重管理という運用リスクを完全に排除しました。
まとめ：ID管理の脱サイロ化がもたらす価値
今回のプロジェクトを通じて、Microsoft Entra IDと、AWSのサーバーレス技術を、CognitoとALBという「ハブ」を通じてシームレスに結合させることができました。
この構成は、以下の魅力があると思っています。
- ガバナンスの強化: 認証の源泉を1つに絞り、ID管理のサイロ化を解消。
- 開発工数の削減: マネージドサービスの活用により、認証周りの開発・テスト工数を省力化。
- 最高水準のセキュリティ: インフラレイヤーでのトークン検証により、実装ミスによる漏洩リスクを構造的に排除。（バグによるセキュリティホールの排除）
技術選定において、エンタープライズが抱える組織的制約を理解した上で、極力マネージドサービスを活用することそれ自体が様々なリスクを下げ、結果として優れたアーキテクチャになることを再認識しました。
今回の構成、事例がどなたかのお役に立つと幸いです。