シングルサインオン

シングルサインオンとは

シングルサインオン (Single Sign-On, SSO) は、ユーザーが 1 回の認証で複数のアプリケーションやサービスにアクセスできる仕組みである。仕組みの骨格は「認証の判断を 1 か所に集めること」で、各アプリはパスワードを自分で預からず、ID プロバイダー (IdP) が発行した署名付きの証明を検証してログインを成立させる。企業環境では、メール、チャット、CRM、経費精算、Wiki など数十のアプリケーションに個別のパスワードでログインする代わりに、1 回のログインですべてにアクセスできる。

セッションは二層になる

SSO の挙動を読む鍵は、セッションが 2 つの層に分かれることである。

IdP セッション: IdP のドメインに置かれた Cookie。「この人は認証済み」という事実を保持する
SP セッション: 各アプリ (Service Provider) のドメインに置かれた Cookie。「このアプリにログイン中」という状態を保持する

2 つ目のアプリでパスワード入力が要らないのは、IdP セッションが生きていて IdP が再認証を省けるからである。一方でアプリ側のセッションは各アプリが独立して持つため、期限も破棄のタイミングもそろわない。後述するログアウトの難しさとアクセス遮断の遅れは、どちらもこの二層構造から出てくる。

認証フロー

各ステップがどちらの層を作っているかに注目すると流れが読みやすい。

1. ユーザーがアプリ A にアクセス (SP セッションなし)
2. アプリ A が IdP (Identity Provider) にリダイレクト
3. ユーザーが IdP でログイン (ID/パスワード + MFA) → IdP セッション成立
4. IdP がトークン (SAML アサーション or JWT) を発行
5. アプリ A がトークンの署名・宛先・期限を検証 → アプリ A の SP セッション成立

6. ユーザーがアプリ B にアクセス (SP セッションなし)
7. アプリ B が IdP にリダイレクト
8. IdP セッションが生きているため、再認証なしでトークンを発行
9. アプリ B がトークンを検証 → アプリ B の SP セッション成立 (パスワード入力なし)

トークンは 1 回使えば役目を終える引換券で、以降のリクエストを支えるのは各アプリの SP セッションである。ここを混同すると、「トークンの有効期限を短くしたのに画面がログアウトされない」という食い違いの理由が見えなくなる。

メリット

ユーザー体験: パスワードの記憶・入力の負担が減る
セキュリティ: パスワードの使い回しが減り、MFA を IdP で一元的に適用できる
管理効率: 入社・異動・退職に伴うアカウント作業が IdP に集約される
コンプライアンス: 認証ログを一元管理でき、いつ誰がどのアプリに入ったかを追える

ただし「退職時に IdP のアカウントを無効化すれば全サービスから即座に遮断できる」とまでは言えない。無効化で止まるのは新しいログインとトークンの再発行であり、すでに成立している SP セッションは各アプリの期限が来るまで有効なままになり得る。即時性が必要なら、重要なアプリの SP セッションを短く設定する、シングルログアウトを実装する、アプリ側の失効操作を退職手続きの手順に組み込む、のいずれかを用意しておく。

実装プロトコル

どの方式でも「IdP が署名した証明をアプリが検証する」という骨格は同じで、違いは証明の形式と想定するクライアントである。

プロトコル	形式	用途
SAML 2.0	XML ベース	エンタープライズ (Okta, Microsoft Entra ID)
OpenID Connect	JSON/JWT ベース	Web/モバイルアプリ
Kerberos	チケットベース	Windows Active Directory

SAML 2.0 は先行世代の仕様で、社内の ID 基盤や連携先の SaaS が SAML しか話せない場面で使う。OpenID Connect は OAuth 2.0 の上に認証レイヤーを追加したもので、JSON と JWT で完結するためモバイルアプリや SPA 向けのライブラリが揃っており、新規に選べるなら実装は軽い。Kerberos は鍵配布センターから受け取ったチケットをブラウザが自動で提示する方式で、社内ネットワークとドメイン参加端末を前提とする。形式ごとの中身は SAML と OIDC で扱う。

AWS IAM Identity Center

AWS IAM Identity Center (2022 年に AWS SSO から改称) は、AWS アカウントと SAML 対応アプリケーションへの SSO を提供する。

[ユーザー] → [IAM Identity Center] → AWS アカウント A (管理者ロール)
                                   → AWS アカウント B (開発者ロール)
                                   → Slack (SAML)
                                   → GitHub (SAML)

Active Directory や外部 IdP (Okta, Microsoft Entra ID) と連携
AWS マネジメントコンソールと CLI (aws sso login) の両方に対応
アカウントごとに異なる権限セット (Permission Set) を割り当て

ここでも二層構造は現れる。アクセスポータルのセッション期間と、権限セットから払い出される一時的な認証情報の有効期限は別の設定であり、前者を短くしても払い出し済みの認証情報は期限まで有効である。

Cognito での SSO

自社アプリケーションに SSO を実装する場合、Cognito ユーザープールをフェデレーション IdP として使える。Google、Apple、Facebook のソーシャルログインや、企業の SAML IdP と連携する。このときユーザープールは、外部 IdP に対しては証明を受け取る側、自社アプリに対しては証明を発行する側という二役を持つ。外部 IdP を増やしてもアプリ側の実装は 1 つで済むのがこの構成の利点である。

よくある落とし穴

シングルログアウトが難しい

1 つのアプリからログアウトしても、他のアプリの SP セッションは残る。IdP セッションを消しても、すでに成立した SP セッションには何も届かないからである。全体を落とすには IdP が各アプリへ破棄を伝える必要があり、経路は 2 つある。

フロントチャネル: ユーザーのブラウザに各アプリのログアウト URL を iframe などで踏ませる。Safari と Firefox が既定で第三者 Cookie を遮断しているため (2026 年 8 月時点)、埋め込み先に Cookie が送られず破棄が空振りしやすい。しかも失敗しても画面上は成功に見える
バックチャネル: IdP から各アプリのサーバーへ、破棄対象のセッション識別子を含むトークンを直接送る。ブラウザの制約を受けない代わりに、アプリ側がその識別子と自分のセッションの対応表を保持し、受信して実際に破棄する実装を持っていなければ何も起きない

OpenID Connect ではこの 2 経路が Front-Channel Logout と Back-Channel Logout として別の仕様になっており、SAML 2.0 にも Single Logout プロファイルがある。いずれも連携先すべてが対応していなければ「一部だけログアウトされた」状態で終わる。そのため完全なシングルログアウトを前提にせず、重要なアプリの SP セッションを短くして IdP への再確認を頻繁に走らせる設計に寄せることが多い。

IdP の単一障害点

IdP がダウンすると、新規ログインとトークンの再発行が止まる。すでに SP セッションを持っているユーザーは期限までは動き続けるため、影響は「全員が即座に使えなくなる」のではなく「時間の経過とともに入れない人が増える」形で広がる。IdP の可用性設計に加えて、管理コンソールへの緊急用の経路を SSO の外に 1 つ残すかどうかを導入時に決めておく。

認証と認可を同じものとして扱う

SSO が各アプリへ配るのは「誰であるか」で、「何ができるか」は各アプリの権限設計が持つ。IdP のグループを各アプリのロールへ写す対応表は別に必要であり、ここを設計しないと全員が同じ権限で入れるだけの状態になる。

体系的に学ぶなら関連書籍を参照してほしい。

サイト情報

シングルサインオン