AWS でアプリケーションを運用する場合、Amazon Cognito をはじめ、OIDC や SAML といった複数の認証方式が選択肢として登場します。
しかし、これらの違いや使い分けは、初学者にとって分かりづらいポイントでもあります。
初めて AWS でアプリを構築する方にとって、
- AWS における認証の仕組みがよく分からない
- Cognito・OIDC・SAML といった用語の違いが理解できない
- 自分のアプリにどの認証方式を採用すべきか判断できない
といった疑問が出てくるのは自然なことです。
そこで本記事では、AWS 上のアプリケーションに認証を追加する代表的な 3 つの方式について、初心者向けに丁寧に解説します。
Amazon Cognito を中心に、OIDC や SAML との違い・役割・使いどころを整理し、認証の全体像を理解できる構成としています。
AWS で認証を追加する代表的な 3 つの方式
AWS 上のアプリに認証機能を追加するとき、よく登場する方式は次の 3 つです。
- Amazon Cognito（認証基盤をセットで提供）
- OIDC（外部 ID プロバイダー）連携による認証
- SAML（エンタープライズ IdP）連携による認証
いずれも AWS だけで完結するのではなく、必要に応じて外部サービス（Entra ID や Google ）
とも連携しながら認証を実現します。
本記事では、それぞれの「役割」と「使いどころ」にフォーカスして解説します。
認証方式①：Amazon Cognito（最もスタンダード）
Amazon Cognito は、AWS が提供するマネージドな認証・ユーザー管理サービスです。ユーザー情報の保存、ログイン画面の提供、多要素認証（MFA）、パスワードリセット、外部プロバイダーとの連携など、認証に必要な機能がひととおり揃っています。
Cognito の主な機能は次の通りです。
- ユーザープール：アプリケーションが扱うユーザーを管理（ID・パスワード・メールアドレスなど）
- Hosted UI：サインイン／サインアップ画面を自動生成
- MFA 対応：Microsoft Authenticator などのアプリを使った多要素認証
- トークン発行：認証が成功したユーザーに ID トークン / アクセストークン を発行
- 外部プロバイダー連携：OIDC / SAML を使って Entra ID や Google と連携
イメージとしては、「ログインまわりをまるごと Cognito に任せて、アプリはトークンを検証するだけ」という構成になります。
自前でログイン画面やパスワードリセット機能を作り込む必要がないため、アプリ開発に集中できるのが大きな利点です。
Cognito のメリット
- ユーザー管理からログイン画面まで「認証基盤」が一式揃っている
- Entra ID や Google などの OIDC / SAML プロバイダーとも連携できる
- ALB や API Gateway と組み合わせて、Web アプリ / API のどちらにも対応可能
- マネージドサービスのため、セキュリティパッチや可用性は AWS 側が面倒を見てくれる
Cognito のデメリット・注意点
- 設定項目が多く、最初はどこを触ればよいか分かりづらい
- email を必須属性にしているのに、外部 IdP 側のユーザーにメールアドレスが設定されていないと 401 エラーになるなど、「属性まわり」でハマりやすい
- GUI からの設定と、内部の概念（ユーザープール・クライアント・ドメインなど）の対応関係に慣れるまで時間がかかる
ただし、一度構造を理解してしまえば、Cognito は AWS 上の認証方式の「中心」として長く使えるサービスです。
まずは小さな検証環境を作り、Hosted UI を使ったサインイン〜アプリ表示までを体験してみるのがおすすめです。
認証方式②：OIDC（外部 ID プロバイダー）連携による認証
2つ目は、OIDC（OpenID Connect）を使って外部プロバイダーと連携する方式です。
代表例としては、次のようなパターンがあります。
- Entra ID（旧 Azure AD）を OIDC プロバイダーとして利用し、Cognito や ALB と連携
- Google / GitHub アカウントでログインさせる「ソーシャルログイン」
- 社内の IDaaS（Okta など）を OIDC で連携
OIDC は OAuth 2.0 をベースにした認証プロトコルで、「ユーザーの本人性をトークンとしてやり取りする」仕組みです。Cognito 自身も OIDC を話すことができ、また Cognito が「ブローカー」となって OIDC プロバイダーとアプリの間を中継する構成も一般的です。
OIDC 連携のメリット
- 既に社内で使っている認証基盤（Entra ID など）をそのまま活用できる
- ユーザーは「いつものアカウント」でログインできるため、ID 管理がシンプルになる
- OAuth2.0 / OIDC ベースのため、モダンな Web / モバイルアプリと相性が良い
- 外部プロバイダー側で MFA やパスワードポリシーを集中管理できる
OIDC 連携のデメリット・注意点
- 外部プロバイダー側と AWS 側（Cognito や ALB）の両方で設定が必要になる
- クレーム（email / preferred_username など）のマッピングを誤ると、Cognito 側でユーザー属性が不足してエラーになる
- テナント ID、クライアント ID、シークレット、リダイレクト URL など、設定する値が多くなりがち
すでに Entra ID を使っている企業であれば、「ユーザー認証は Entra ID に任せ、Cognito は連携とトークン管理に専念させる」といった構成が取りやすくなります。
認証方式③：SAML（エンタープライズ IdP）連携による認証
3つ目は、SAML（Security Assertion Markup Language）を使ったエンタープライズ向け認証です。
SAML は古くから企業のシングルサインオン（SSO）で利用されてきた標準規格で、Active Directory や Entra ID、各種クラウドサービスなど、多くのエンタープライズ IdP / SP でサポートされています。
AWS では、次のようなパターンで SAML が利用されます。
- Cognito のアイデンティティプロバイダーとして Entra ID（SAML）を登録し、Cognito 経由でアプリにログイン
- ALB の認証先として SAML IdP（Entra ID や他社 IdP）を指定し、ALB 経由で EC2 の Web アプリへ SSO
SAML 連携のメリット
- 既存のエンタープライズ認証基盤（Entra ID や AD FS 等）をそのまま使える
- 社内システムとクラウドアプリをまとめて SSO 対応にしやすい
- 企業での実績が多く、運用ノウハウが豊富
SAML 連携のデメリット・注意点
- XML ベースで少し古い仕様のため、OIDC と比べると実装が重い
- SAML アサーション内のクレーム（emailaddress など）を正しく設定しないと、Cognito 側でユーザーを特定できずエラーになる
- トラブルシュート時にログを読み解くのが難しいケースがある
以下の記事でまとめている「Cognito × Entra ID（SAML）」の構成では、SAML のクレームに emailaddress が入っておらず、Cognito 側の必須属性と噛み合わなかったことで 401 エラーが発生していました。このように、「どの属性をどの必須項目と紐づけるか」は SAML 連携での典型的なハマりどころです。
【図解】Amazon Cognito × Entra IDでSAML SSOを実現
どの方式から始めるべきか？
ここまで 3 つの方式を見てきましたが、「結局どれを選べばいいの？」という視点で整理すると、次のようなまとめになります。
✔ まずは Cognito 単体から始める
クラウド初心者であれば、まずは Cognito ユーザープールと Hosted UI だけを使って小さな検証環境を作るところから始めるのが一番おすすめです。
外部プロバイダーと連携しない構成であれば、設定項目も比較的シンプルで、
「認証 → トークン発行 → アプリ」という基本の流れを掴みやすくなります。
✔ 社内の Entra ID と連携したい場合
すでに社内で Entra IDなどを利用している場合は、
OIDC または SAML を使って Cognito と連携する構成が有力候補になります。
- モダンな Web / モバイルアプリ中心 → OIDC 連携 を優先的に検討
- 既存の SAML ベースの SSO 基盤がある → SAML 連携 で合わせる
どちらにせよ、「Cognito をハブとして Entra ID など外部 IdP をぶら下げる」形にしておくと、将来別のアプリを追加したいときにも流用しやすくなります。
初心者が特にハマりやすいポイント
Cognito / OIDC / SAML いずれの方式でも、初心者が共通してつまずきやすいのは次のポイントです。
- 必須属性と外部 IdP 側のクレームが噛み合っていない
例：Cognito 側で email を必須にしているのに、Entra ID のユーザーにメールアドレスが設定されていない。 - リダイレクトURLの指定ミス
Cognito のコールバック URL に ALB の/oauth2/idpresponseを入れ忘れる、スキーム（http/https）が合っていないなど。 - クライアント ID / シークレットの取り違え
Entra ID 側のアプリ登録で発行した値と、Cognito や ALB に設定した値が一致していない。
特に「email の有無」は、401 エラーの原因となり、ハマりやすいポイントの１つです。
ユーザープールの必須属性をどう設計するか、外部 IdP 側でどの属性を返すかは、
最初にきちんと整理しておくのがおすすめです。
3つの方式の比較
最後に、本記事で紹介した 3 つの方式を簡単に比較しておきます。
まとめ
AWS でアプリに認証機能を追加する際は、「Cognito」「OIDC（外部プロバイダー）」「SAML」という 3 つのキーワードを押さえておくと全体像が掴みやすくなります。まずは Cognito 単体で動作を理解し、その上で OIDC や SAML を使った Entra ID 連携などへステップアップしていくのが、学習・検証のしやすい進め方です。
本記事の内容をベースに、Cognito と Entra ID を組み合わせた構成や、ALB 認証との連携など、より実践的なパターンにもぜひチャレンジしてみてください。
コメント