はじめに
こんにちは！パナソニック コネクト株式会社の田中です。
今回は、先日AWSさんが主催してくださったAI-DLC UnicornGym in 大阪 の最終日にライトニングトーク(LT)にて本記事の内容を登壇させていただいたのでその内容をベースに今回技術記事としてまとめました。
登壇していた時の写真をイラスト化してもらいました
目次
- SSO(シングルサインオン)とは
- AWS Cognitoとは
- 導入課題
- 試したこと
- 反省点
1. SSO(シングルサインオン)とは
1回の認証（ログイン）で、複数のシステムやサービスを利用できる仕組みです。
SSO導入のメリット:
-
01 ユーザー利便性向上:
複数のパスワードを覚える必要がなくなり、ログインの手間が大幅に削減されます。 -
02 セキュリティ強化:
パスワードの使い回しを防ぎ、強固な認証基盤を通じて安全性を高めます。 -
03 管理コスト削減:
パスワード忘れによるリセット対応など、IT管理者のサポート負担を軽減します。
2. AWS Cognitoとは
ウェブアプリやモバイルアプリに迅速かつ簡単にユーザーのサインアップ/サインイン、アクセスコントロールを追加できるフルマネージドなAWSのサービスです。
主な特徴:
- 数百万人のユーザーにスケール可能な設計
- SAML 2.0、OpenID Connectなどの標準プロトコル対応
- ソーシャルログインやエンタープライズID連携が容易
- 各種セキュリティ基準への準拠
- Cognito User Poolというユーザー管理機能
- Managed Login 画面の提供(Amplifyとの相性も良い)
Cognitoサービスが提供するログインUIを通して、簡単に認証と自身のWebサービスへの連携を可能にします。
AWS公式ドキュメント - Amazon Cognito とは
3. 導入課題
SSOログイン機能の導入において、主に以下の2つの課題がありました。
1. 既存のログインの仕組みの考慮
-
IDとパスワードの管理:
既存のシステムでは、IDとパスワードはDB(AWS Aurora)で管理し、Laravelでセッション情報を生成していました。 -
Cognitoとの連携:
CognitoがIdPとの認証に成功した際に返すID Tokenと、既存のRDSデータの紐づけをどのように行うかが課題でした。具体的には、ユーザーが入力したID/パスワードと既存DBを照合し、認証が成功したらCognitoのセッションを生成し、ホーム画面へ遷移させる必要があります。
2. Cognito Hosted UIを使わない方法の調査
-
カスタムUIでの認証要件の実現:
Cognito標準のManaged Loginは導入が簡単ですが、デザインのカスタマイズ性に制限があります。
当社のサービスUI/UXと完全に統合するためには、カスタムログイン画面の実装が必須でした。
また、お客様テナントに対応したIdPログインページへ直接遷移させたいという要件もありました。
Cognito User PoolのUI選択肢パターン
AWS公式が提唱するUI選択肢は2パターンに、カスタムUI要件を満たすためのハイブリッドなアプローチを加えた3パターンを検討しました。
-
Managed Login: AWS提供のホスト型ログイン画面を利用し、認証UIをCognito側で管理する方式。
-
Custom UI(SDK): ログイン画面を独自に実装し、CognitoのAPI/SDKと連携して認証する方式。
-
ByPass Managed Login/Hybrid: Managed LoginのUIページだけを自前UIに置き換え、機能はManaged Loginのものを扱う方式。
今回の要件では、既存のUI/UXを維持しつつCognitoの機能を活用するため、このハイブリッドなアプローチを採用することになりました。
Amazon Cognito の Hosted UI を使用するか、カスタム UI を作成するか
4. 試したこと
1. サンプルwebアプリを作成しながら検証
検証環境でのPoC（概念実証）を実施しました。
- セッショントークンの取得・保持方法の検証
- 全ページのハイブリッドパターンの検証・設計の実施
Hosted UIを経由せず、特定のIdPログイン画面へリダイレクトするためのオプションとして、認可エンドポイントのパラメーターにidentity_provider=<IdP名>を付与する方法を試しました。
WebアプリケーションにAmazon Cognitoでログインしたい時に何を作成すればいいか
2. 実装期間とコード変更量
Copilotにほぼコーディングしてもらいましたが、既存画面にSSOの画面とAPIの追加などは次のような期間と変更量になりました。
- 実装期間: 約3ヵ月
- コード変更量: 約850ステップ
各区分のステップ数:
| 区分 | 言語 / 技術 | ステップ数 |
|---|---|---|
| 画面 | React/TSX・TS | 383 |
| API | TypeScript | 297 |
| API | PHP | 91 |
| API合計 | TypeScript・PHP | 388 |
| インフラ | TypeScript (CDK) | 71 |
| 総計 | TSX・TS・PHP | 842 |
3. CognitoとWebアプリ構成
開発環境(Dev)、ステージング環境(Stg)、システムテスト環境(Systemtest)、本番環境(Prd)それぞれにCognitoユーザープールとアプリケーションクライアントを設定し、Webアプリケーションと連携させました。IdP情報は開発者が個別に手動で設定します。
5. 反省点
本番環境のCognitoが最初動作しなかった件
社内のIdP基盤登録申請の際に、ACS URLのユーザープールIDを間違えて申請してしまったことが原因でした。
Cognitoドメインを使う必要がある箇所で、誤ってユーザープールIDを記載してしまったため、本番環境でCognitoが正常に動作しませんでした。
ACS URL例
https://Your user pool domain/saml2/idpresponse
問題の具体例:
(修正前) ACS URL (Assertion Consumer Service URL)
https://ap-northeast-1_ドメイン/saml2/idpresponse
→ <リージョン>_ID で間違えて申請
(修正後) ACS URL (Assertion Consumer Service URL)
https://ap-northeast-1ドメイン/saml2/idpresponse
最も良い対応方法:
Cognitoドメインをカスタムドメインに変更することで、このような設定ミスを防ぎ、より柔軟な運用が可能になります。
https://auth.example.com
参考記事
Amazon Cognito の承認エンドポイント – identity_provider パラメータ
Amazon Cognitoユーザープールのカスタムドメイン設定
SmartHR ヘルプセンター - SAML SSO を設定する方法
注意事項
本記事に掲載している内容は、あくまで一般的な技術情報と個人の見解に基づくケーススタディであり、特定のサービスの品質を評価・断定するものではありません。また、所属する組織の立場や戦略、意見を代表するものでもありません。