CognitoのマネージドログインはSSOとして使えるのか？制約と割り切りポイント
はじめに
本ブログは、CognitoのマネージドログインをIdP（SSO基盤）として採用してよいか判断したい人向けに書いています。
「SSOとして期待される体験」と「Cognitoが実際に提供するもの」のギャップを明確にすることを目的としています。
最初に結論
「導入は容易だが、SSO用途としては明確な制約があり、割り切りが必要」です。
特に以下の制約は、設計・運用・UXに大きく影響します。
- SSOセッション1時間固定で延長できない
- ログイン画面の文言・導線が変更ができない
- 全アプリ即時ログアウトが難しい
そのため、本格的なSSO体験を前提に設計すると、後から必ずギャップが出るというのが結論です。
これらの制約を正しく理解するためには、まず「Cognitoのマネージドログインが何を提供し、何を提供しないのか」を整理する必要があります。
Cognitoのマネージドログインとは
Cognitoのマネージドログインは、AWSが提供するログイン画面を利用して、認証を簡単に実装できる仕組みです。
前章で「SSO用途としては制約がある」という結論を述べました。
その制約を正しく理解するために、まずCognitoのマネージドログインが何を提供し、何を提供しないのかを整理します。
Cognitoが担当するもの
- ログイン画面
- ログイン画面のログイン状態維持（SSOセッション）
- ID/アクセス/リフレッシュトークンの発行
Cognitoが担当しないもの
- 各アプリ側でのログイン状態維持
ここで重要なのは、 マネージドログインの「SSOセッション」 と 各アプリのログインセッション が完全に別物だということです。
次の図は、「CognitoのSSOセッション」と「各アプリのセッション」が完全に独立していることをイメージしています。
また、従来型のWebアプリケーションであればCookieセッション、
SPAであればトークン管理などを利用して、 各アプリの責務でログイン状態の維持 をすることになります。
次の図は、ログイン済みの各アプリ（App A）がIDトークンの期限が切れていた場合、リフレッシュトークンを利用してIDトークンの更新をしてログイン状態を継続させていることをイメージしています。
こういったトークンの確認と管理がアプリ側に求められます。
SSOで期待される体験
Cognitoが提供する機能範囲を整理したところで、次に「一般的にSSOに何が期待されるのか」を上げます。
- 1度ログインすれば複数アプリで再ログイン不要
- 統一されたログインUIによるブランド体験
- (必要に応じて)全アプリを即時ログアウト
この「SSOで期待される体験」と、「Cognitoのマネージドログインが提供するもの」を踏まえると、両者の間にはいくつか明確なギャップが存在します。
ここからは、その具体的な制約を見ていきます。
制約事項
制約1. SSOセッションが1時間固定（延長不可）
通常SSOというと、1度ログインしたら対象の全てのアプリケーションが利用できることを期待されます。
しかし、マネージドログインのSSOセッションは 1時間固定 という強い制約があります。
そのため、ログインから1時間超えると再ログインを求められるという体験がおきます。
この内容はドキュメントに次のように記載されています。
ドキュメントの引用
マネージドログインとホストされた UI の １ 時間のセッション Cookie
ユーザーがログインページまたはサードパーティプロバイダーからサインインすると、Amazon Cognito はユーザーのブラウザに Cookie を設定します。この Cookie を使用すると、1 時間以内なら、ユーザーは同じ認証方法で再度サインインできます。ブラウザ Cookie を使用してサインインすると、アプリケーションクライアント設定で指定した期間にわたり、ユーザーは新しいトークンを付与されます。ユーザー属性または認証要素を変更しても、ブラウザ Cookie を使用して再度サインインする機能には影響しません。
セッション Cookie による認証では、Cookie の期間は別の 1 時間にリセットされません。最後に成功したインタラクティブ認証から 1 時間を超えてサインインページにアクセスする場合、ユーザーは再度サインインする必要があります。
よって、各アプリはトークン更新でログイン継続できているのに、マネージドログイン側は1時間を超えると突然SSOが切れるように見えるという二重構造が発生します。
制約2. ログイン画面のデザインや文言が変更できない
Cognitoマネージドログインでは、次のような仕様となっています。
- ロゴ・色などの簡易ブランディングは可能
- 表示テキストの変更は不可（ローカライズ除く）
SSOは各プロダクトの入口になるため、ブランドイメージが重要視されることがよくあります。
これを重視する場合、マネージドログインではかなり大きい制約があります。
ロゴ、色などがどの程度デザイン変更できるかについては、こちらのブログをご覧ください。
また、AWSのドキュメントに テキストを変更またはローカライズすることはできません。（例外：ローカライズ適用） と明記されています。
制約3. ログインフローへの任意画面差し込みができない
SSOでは次のような要件がよくあります。
- 初回ログイン時の追加プロフィール入力
- 規約同意、年齢確認などを「認証途中」で必須化
マネージドログインでは認証フローの途中に固有画面を挟むことはできません。
結果として、認証後にアプリに戻ってから、アプリ側で追加入力/同意/補完を行う必要があります。
※補足：規約URLの表示機能はあります。サインアップ画面にTerms/Privacyへのリンクを出せます。詳しくはこちらのブログをご覧ください。
ただし「自社の同意画面を挟んでブロックする」など、自由な分岐とは別物なので、要件によっては不足します。
制約4. 全アプリ即時ログアウト（シングルログアウト）が困難
Cognitoが管理するのは認証とトークン発行までです。
認証完了後のトークンは、各アプリで保持することになります。
それに関連して、 各アプリのログイン状態を全て無効にする という操作を行うことが困難です。
他のSSO製品が採用している、SAMLやOIDCで規定されているような、シングルログアウトの仕組みはありません。
認証トークンとしてJWTを使う以上、リアルタイムな失効確認は困難です。
Cognitoが発行した リフレッシュトークンを無効化 することはできます。
そのため、各アプリ向けには、短命のID/アクセストークンを発行し、期限が切れるまで各アプリはログアウトされないことを許容するという割り切りが必要です。
※補足として、SAML IdP連携時のSLOは存在するが、CognitoをIdPとして使う場合には無関係
制約5. “デバイスを記憶してMFA省略”のUXはマネージドログインでは提供されない
次のドキュメントのように、Cognito自体には「remembered devices」によって、信頼済み端末ならMFAをスキップする仕組みがあります。
しかし、この機能はマネージドログインでは提供されていません。
SSO製品でよくある、「30日間この端末ではMFA不要」みたいなことができません。
マネージドログインをSSOとして採用するとしたら
ここまでの制約を踏まえると、マネージドログインを「SSO基盤」として積極的に推奨できるケースは多くありません。
それでも、次のような前提条件を明確に置けるのであれば、選択肢として成立する場合があります。
向いているケース
- PoC / 小規模 / 早期立ち上げ
- UXやSSO体験をある程度割り切れる
- コストの低さが何よりも最優先
避けたほうが良いケース
- SSO体験（1回だけのログイン・即時ログアウト）が必須
- ブランドイメージを重視したい
- 端末信頼等、セキュリティを向上させつつ、利便性も追求したい
まとめ
Cognitoのマネージドログインは「簡単に認証を実装したい」用途には非常に優秀です。
一方、SSO基盤として採用する場合は、制約を理解した上で、明確に割り切る必要があるというのが私の結論です。
「SSOとしてユーザーにどういう体験を提供したいか？」というところを考え、コストとの兼合いを考え、「どのSSO体験を諦められるか」を決めたうえで採用判断することを強くおすすめします。
