2026.03.16
外部IdP連携 × Amazon Cognitoで発生した設計課題 ― 認証は成功するのに、業務が止まる理由とは ―
アプリケーション開発において、ユーザー認証は欠かせない要素の一つです。
特に既存の社内ID基盤を活用しながらクラウドへ移行する場合、外部IdPとAmazon Cognitoを組み合わせる構成は一般的です。
Amazon CognitoはAWSが提供するフルマネージドな認証基盤であり、OAuth/OIDC/SAMLへの対応、MFAやソーシャルログイン、Lambdaによるカスタマイズなど、機能面では非常に優れています。
しかし今回のプロジェクトで、私たちは、「認証は成功しているのに、業務が動かない」という状況に直面しました。
本記事では、その原因と設計の見直しポイントを共有します。
なぜAmazon Cognitoを採用したのか
ユーザー認証を自前で構築する場合
・パスワード管理
・MFA実装
・トークン管理
・セキュリティアップデート対応
・OAuth/OIDC仕様理解
など、多くの負担が発生します。
Cognitoを利用することで、これらの課題をクラウド側に任せ、開発チームは業務ロジックに集中できます。
さらに
・外部IdPとの連携
・AWSサービスとの統合
・スケーラビリティ確保
といった点も評価し、採用に至りました。
設計当初は、「認証はIdPに任せるため、Cognito側はシンプルになる」と、考えていました。
発生した課題
プロジェクトは、5,000ユーザー規模のBtoB向け業務システム刷新案件でした。
外部IdPとCognitoをOIDC連携する構成です。
問題は結合テスト段階で発覚しました。
・外部IdPでの認証は成功
・CognitoからIDトークン／アクセストークンも返却
・しかしアプリ側でユーザーを一意に特定できない
結果として、
・ロール別画面制御が動かない
・業務データの表示制御が崩れる
という事象が発生しました。
ログインはできるのに、業務が使えない。
私たちは急いで調査を開始しました。
原因：属性設計の見落とし
調査を進めると、外部IdPから渡されるユーザー属性が想定より限定的であることが分かりました。
・社内で一意なユーザーIDがトークンに含まれていない
・メールアドレスは取得できるが業務上は一意ではない
・環境ごとに属性仕様が微妙に異なる
・認証は成功している
・しかし業務ユーザーとして扱えない。
ここで初めて、「認証と業務識別は別問題であること」を認識しました。
設計の見直し
見直し①：Cognitoを業務識別の基盤として扱う
方針を変更し、Cognitoを単なる通過点ではなく「業務ユーザー識別の基盤」として設計し直しました。
具体的には、
・カスタム属性 custom:employeeId を追加
・外部IdPの従業員番号をAttribute Mappingで明示的に紐付け
・Cognitoのsubと業務識別子を確実に管理
という構成に変更しました。
これにより、「ログイン成功＝業務ユーザー特定可能」という状態を実現できました。
見直し②：責務の明確化
再設計後の整理は以下です。
領域役割外部IdP本人確認Cognitoユーザー識別・属性管理アプリ業務ロジック
この整理により、
・トークンから必要情報を安定取得
・将来IdP変更時の影響最小化
・業務ロジックの単純化
が可能になりました。
今回の経験から得た教訓
外部IdP連携では、実装よりも設計判断が重要です。
特に以下は事前確認が必要です。
・IdPから取得できる属性一覧
・業務上一意な識別子の定義
・Attribute Mapping設計
・環境差異の有無
・トークン内クレームの実動確認
認証基盤は、一度本番稼働すると変更コストが高くなります。
「今は動いているから問題ない」ではなく、業務で使い続けられる設計かどうかを基準に考える必要があります。
まとめ
Amazon Cognitoは非常に有効な認証基盤です。
しかし、外部IdP連携を前提とする場合、
・属性設計
・業務識別方針
・責務分離
を整理しなければ、「ログインできるが使えないシステム」になり得ます。
認証基盤は「ログイン可否」ではなく、 「業務が止まらないかどうか」で評価すべき領域です。
本番稼働前に設計を整理しておきませんか？