シングルサインオン（SSO）
Google Workspace を IdP に、AWS などと SAML で連携する仕組みとメリット
SSO では、ログインは身元の元締め（IdP）への 1 回だけです。各サービスはパスワードの代わりに、IdP が発行する署名付きの保証書を確かめて通します。
- パスワードを入れる相手は IdP（Google）だけ
- 2 つ目以降のサービスは再入力なしで入れる
- 退職時は IdP を止めるだけで全部から締め出せる
なぜ1回のログインで全部に入れるのか
仕事で使うクラウドサービスは増える一方です。サービスごとに ID とパスワードを作ると、使い回しや退職者アカウントの消し忘れなど危ない隙が生まれます。SSO は、そのログインを身元の元締め（IdP）に 1 か所へ集める仕組みです。
シングルサインオン（SAML 連携）の流れ
各ステップ・参加者・分岐をクリックすると、その仕組みの説明がここに表示されます。
この図をテキストで読む
シーケンス図「シングルサインオン（SAML 連携）の流れ」。参加者3人、ステップ13個。 【参加者】（左から右） - あなた: ブラウザ - サービス: AWS など / SP - Google Workspace: 身元の元締め / IdP 【流れ】（上から下へ） ── ① 事前準備（管理者が信頼関係を結ぶ・1回だけ） ── 1. Google Workspace → サービス: 署名用証明書つきメタデータを交換 ── ② はじめてのログイン（サービス起点の SAML） ── 2. あなた → サービス: サービス（AWS 等）にアクセス 3. サービス → あなた: Google でログインしてと誘導（認証要求）（応答） 4. あなた → Google Workspace: Google アカウントでログイン（＋MFA） 5. Google Workspace（自身で処理）: 本人確認OK → 署名付きアサーションを発行 6. Google Workspace → あなた: アサーションをブラウザに返す（応答） 7. あなた → サービス: アサーションをサービスへ提示 8. サービス（自身で処理）: 署名を検証し、属性から権限を決定 9. サービス → あなた: アクセス許可（一時的な権限を付与）（応答） ── ③ 2つ目のサービスへ（ここが SSO の効きどころ） ── 10. あなた → サービス: 別のサービスにアクセス 11. あなた → Google Workspace: Google は既にログイン済み（パスワード不要） 12. Google Workspace → あなた: すぐ新しいアサーションを発行して返す（応答） 13. あなた → サービス: 保証書を提示 → 検証して入室OK
退職者は『1か所』止めるだけ
退職時は Google アカウントを無効化するだけで、連携した全サービスから即座に締め出せます。半面、元締め（IdP）が破られると連携先すべてが危険にさらされるため、IdP 自身は MFA 必須など特に厳重に守ります。
押さえておきたい用語
- シングルサインオン（SSO）
- 1か所（IdP）にログインすれば、連携した複数のサービスへパスワードを入れ直さずに入れる仕組み。
- IdP（アイデンティティプロバイダ）
- 身元を一元管理し、本人確認して保証書を発行する元締め。Google Workspace や Okta が代表例。
- SAML
- IdP と SP が本人確認の結果を安全にやり取りする共通ルール。保証書をブラウザ経由で受け渡す。OIDC も同じ考え方の規格。
- アサーション（保証書）
- 『確かに本人で、こういう所属・権限』と IdP が証明する署名付きデータ。短い有効期限つき。
- フェデレーション / メタデータ
- IdP と SP が証明書入りの設定を事前に交換し、互いを信頼相手として登録すること。SSO の前提。
ここから先へ
この解説とつながりのあるページ