Amazon Cognitoで試す Google Social Login と Google Workspace SAML SSO のセットアップ比較
はじめに
「Googleでログイン」とひとことで言っても、AWS Cognitoでつなぐ方法は1つではありません。
実際に試してみると、Google Social Login と Google Workspace SAML SSO は見た目こそ近いものの、設定の流れや必要な権限、ハマりどころが少し違いました。
今回は、同じCognito User Poolに対してこの2つをそれぞれ設定してみて、どこが似ていてどこが違うのかを、自分が実際に確認できた内容だけに絞ってまとめます。
なお、User Pool自体は事前に作成済みの前提で進めます。User Poolの作成手順はこの記事では扱いません。
検証環境
- AWS Cognito
- Chrome
- Google Social Login用: Google Cloud
- Google Workspace SAML SSO用: Google Workspace
どちらの設定でも、管理画面を触れる権限は必要です。
先に結論
先にざっくり整理すると、今回の検証で感じた違いはこんな感じでした。
Google Social Loginは、比較的すぐ試しやすいGoogle Workspace SAML SSOは、組織向けの設定が多く、相互に設定を合わせる必要がある- Cognito側ではどちらも
Authentication -> Social and external providersから追加できる - 最終的な動作確認は、
App clientのLogin pagesから試すのがわかりやすい
同じ「Googleログイン」でも、前者はSocial Login、後者はGoogle WorkspaceのSAML連携として考えた方が整理しやすかったです。
Google Social Login を設定する
まずは Google Social Login です。
全体の流れ
大まかな流れは以下でした。（詳細はスクショをご参考ください）
- Google CloudでOAuth Clientを作成して、
Client IDとClient secretを取得する - Cognitoの
Authentication -> Social and external providersでGoogleを選ぶ - Google Cloud側にCognitoのリダイレクトURLを登録する
App client側でGoogleを有効にして、Hosted UIで動作確認する
Cognito側で設定したポイント
Google を選ぶと、Google Cloud側で作成した Client ID と Client secret の入力が必要でした。
あわせて Authorized scopes の設定も必要です。ここでは openid が必要でした。
最初、自分はここを * にして広めに許可すれば通るかなと思って試したのですが、これはうまくいきませんでした。少なくとも今回の検証では、必要なscopeを明示的に入れる形で進めるのが正解でした。
Google Cloud側で設定したポイント
Google CloudのOAuth Clientには、Cognitoのリダイレクト先を Authorized redirect URIs に追加する必要がありました。
今回使った形式は以下です。
https://{your-cognito-domain}/oauth2/idpresponse
Cognitoのドメイン部分は、Authentication -> Authentication methods 周辺で確認できるCognito prefix domainから持ってくるのがわかりやすかったです。
このリダイレクトURLがずれていると、Google側へ遷移しても正常に戻ってこられません。
App client 側で忘れずに見るところ
IdPを追加しただけでは終わりではなく、App client の Login pages 側でも設定を確認する必要がありました。
今回の確認ポイントは以下です。
Identity providersにGoogleが入っていることOAuth grant typesでAuthorization code grantを使うことOpenID Connect scopesにopenidが入っていること
設定後に View login page から確認すると、Sign in with Google が表示され、正しく設定できていればそのままログインできました。
Google Workspace SAML SSO を設定する
次は Google Workspace SAML SSO です。
こちらは Google Social Login と違って、Google WorkspaceのAdmin Console側でSAMLアプリを作る流れになります。
全体の流れ
大まかな流れは以下でした。（詳細はスクショをご参考ください）
- Google Workspaceの
Admin Consoleに入る Apps -> Web and mobile apps -> Add app -> Add custom SAML appからカスタムSAMLアプリを作る- Google Workspace側で取得したMetadataをCognitoにアップロードする
- Cognito側で表示される
ACS URLとEntity IDをGoogle Workspace側に設定する Service statusを有効化するApp clientのLogin pagesでSAML IdPを有効にして動作確認する
Google Workspace 側で最初にやること
Google WorkspaceでカスタムSAMLアプリを作成すると、認証情報を取得できます。
今回の流れでは、DOWNLOAD METADATA からMetadataファイルをダウンロードし、それをCognito側のSAML設定で使うのが便利でした。
Cognito側で設定したポイント
Cognitoの Authentication -> Social and external providers から、今度は SAML を選びます。
ここで必要情報を入力し、先ほどGoogle WorkspaceからダウンロードしたMetadataファイルをアップロードしました。
その後、Google Workspace側の Service provider details に、Cognito側の情報を入力します。
今回使った値の形式は以下です。
ACS URL:https://{your-cognito-prefix-domain}/saml2/idpresponseEntity ID:urn:amazon:cognito:sp:<user-pool-id>
Entity ID はARNではなく、user-pool-id を使う形式だった点は特に注意が必要でした。
User Pool IDは Overview ページの上部で確認できました。
Google Workspace 側で最後にやること
Service provider details を入力して完了したあと、Service status で ON for everyone にして、組織としてこのアプリを使える状態にしました。
ここまでやって初めて、Google Workspace経由でCognitoに認証できる状態になります。
App client 側で確認したポイント
こちらも最後は App client の Login pages が重要でした。
今回の確認ポイントは以下です。
Identity providersにSAMLプロバイダーが入っていることOAuth grant typesでAuthorization code grantを使うことOpenID Connect scopesにopenidが入っていること
View login page から確認すると、continue with google-workspace のような形でSAML側のログイン導線が表示され、設定が揃っていればそのままログインできました。
比較してみてわかったこと
実際に両方試してみると、同じGoogleログインでも性格は少し違うと感じました。
1. Google Social Login の方が始めやすい
Google Social Login は、Google CloudでOAuth Clientを用意して、Cognitoに Client ID / Client secret とリダイレクトURLをつなげれば進められるので、比較的シンプルでした。
まず試してみる、という意味ではこちらの方が入りやすいです。
2. Google Workspace SAML SSO は相互設定が多い
一方で Google Workspace SAML SSO は、Google Workspace側とCognito側の両方を見ながら設定を合わせる必要がありました。
特に以下は混ざりやすかったです。
- Metadataをどちらへ渡すのか
ACS URLとEntity IDの役割App client側でIdPを有効化する最後のひと手間
設定自体は難しすぎるわけではないですが、Social Loginよりは「組織向けのSSO設定をしている感」が強かったです。
3. Google Workspace SAML SSO の方が制御しやすい
今回の検証で印象的だったのは、Google Workspace側ではサービスの有効化や組織側の管理が前提になることです。
この制約は手軽さでは不利ですが、そのぶん組織としてのアクセス制御をかけやすい構成だと感じました。
また、属性マッピングを使えば、より多くの情報を連携できる余地がある点も違いとして見えてきました。
4. アプリ側から見ると入口を揃えやすい
Cognitoを間に挟むことで、Google Social Login でも Google Workspace SAML SSO でも、最終的にはCognitoのログイン導線に載せて試せるのはわかりやすかったです。
設定するIdPは違っても、Cognito側でまとめて扱えるので、比較しながら検証しやすい構成でした。
おわりに
今回試してみて、「Googleでログイン」は1種類ではなく、用途によってまったく別物として考えた方が理解しやすいと感じました。
- 不特定のGoogleアカウントで気軽にログインさせたいなら
Google Social Login - 組織のGoogle Workspaceアカウントに絞ってSSOしたいなら
Google Workspace SAML SSO
Cognitoではどちらも同じUser Poolに載せられるので、要件に応じて選びやすいのは便利です。
これから設定する人は、まず App client -> Login pages まで含めて確認することと、Google側へ渡すURLやCognitoへ渡すMetadataの向きを落ち着いて整理することをおすすめします。
