シングルサインオン（SSO）は、ユーザーが中央のアイデンティティプロバイダー（IdP）で一度認証を行うと、その後は認証情報を再入力しなくても複数のアプリケーションにアクセスできる仕組みです。SSOでは、認証の責任を個々のアプリケーションから中央の認証機関に移管し、集約的に認証状態を管理することで、ユーザーのパスワード疲れを解消します。

たとえば、社内ネットワークにログインした後、SlackやGitHub、社内ナレッジベースなどにアクセスする際、アプリケーションごとに再度パスワードを入力する必要がない場合、それはSSOが意図どおりに機能している状態です。

SSOを導入することで、認証制御を一元化し、認証エクスペリエンスを標準化できるため、セキュリティチームと開発チームの双方にとって即効性のある明確なメリットがあります。

セキュリティとコンプライアンスの一元化

• 攻撃対象領域の縮小：認証を単一の認証イベントに集約することで、ユーザーがエコシステム全体で管理する認証情報の数を減らせます。その結果、攻撃対象領域が全体的に小さくなるため、侵害のリスクを低減できます。
• 一貫したポリシーの適用：SSOでは、IdP側で多要素認証（MFA）などの強力な認証ポリシーを一元的に適用できます。そのため、何十個ものシステムで同じセキュリティ対策を個別実装する必要がなくなります。
• 監査対応の簡素化：認証ログが中央管理されるため、監査証跡の作成やコンプライアンス報告が容易になります。また、セキュリティチームは単一の信頼できる情報源を得て、アプリケーションのエコシステム全体でユーザーのアクセス状況を把握できます。

業務効率とユーザーエクスペリエンス（UX）の向上

• 重複実装の排除：SSOを導入すると、開発チームは新たなアプリケーションごとに認証ロジックを個別に実装・保守する必要がなくなるため、コア機能の開発に集中できるようになります。
• サポート業務の負担軽減：SSOを導入することで、パスワードリセットやアカウントロックに関する問い合わせが減少するため、サポートチームはより価値の高い問題に注力できるようになります。
• プロビジョニングの迅速化：ユーザーのオンボーディングやプロビジョニング解除が簡単になります。中央のアイデンティティシステム内で一度設定を変更するだけで、複数のシステムへのアクセス権を一括で付与・削除できるためです。

SSOは、アプリケーション（サービスプロバイダー：SP）とIdPの間の暗号学的な信頼関係に基づき、セキュアなセッションベースのリダイレクトによって実現されます。

SSOの基本的なフロー

1. 初回リクエスト：ユーザーが保護されたアプリケーション（SP）へアクセスしようとします。SPはユーザーがまだ認証されていないことを検知し、ユーザーのブラウザをIdPのログインエンドポイントへリダイレクトします。
2. 認証とIdPセッション：ユーザーは、任意の手段（パスワード、パスキー、生体認証など）を用いてIdPで認証します。IdPはユーザーのアイデンティティを検証した後、認証済みセッションを作成し、セキュアなセッションIDを保存します（通常、この識別子はHttpOnly、Secure、SameSite属性を持つCookieに格納されます）。
3. トークンの発行：IdPは対象アプリケーション向けのセキュリティアーティファクトを付与し、ユーザーをSPへリダイレクトします。

• OASISが策定したSecurity Assertion Markup Language (SAML) 2.0では、このアーティファクトは、ユーザーのアイデンティティクレームを含む、署名付きXMLアサーションです。
• OpenID Foundationが策定したOpenID Connect（OIDC）では、認可コードと、IDトークンおよびアクセストークンの交換が行われます。また、クライアントの種類やスコープによっては、リフレッシュトークンも発行されます。これらの違いについて詳しくは、「認証と認可の違い」を参照してください。

4. アクセスの許可：SPは、アサーションまたはトークンの署名を検証するとともに、有効期限（exp）、有効開始時刻（nbf）、発行者（iss）、対象者（aud）などのクレームを確認し、ユーザーのローカルセッションを確立します。

その後のシームレスなアクセス

同じユーザーが、同じブラウザセッション内で、同じIdPを信頼する別のアプリケーションへアクセスした場合は以下のようになります。

1. 2つ目のアプリケーションは、ユーザーが未認証であることを検知し、IdPへリダイレクトします。
2. IdPは、自身のセッションCookieを確認して、認証済みセッションが存在することを即座に認識します。
3. IdPはユーザーに再認証を求めることなく、そのアプリケーション専用の新しい認証トークンを発行します。
4. ユーザーは2つ目のアプリケーションへシームレスにアクセスできます。

このように、一元化された認証イベントを再利用することが、SSOを支える技術的な基盤です。

モダンなSSOは、アイデンティティ情報や認可情報のやり取りを規定する標準化されたプロトコルに基づいています。柔軟なシステム連携を実現するためには、適切なプロトコルを選択すること（あるいは多くの場合、両方に対応すること）が重要です。

プロトコル	トークン形式	主なユースケース	複雑度
SAML 2.0	XMLアサーション	企業間連携（B2Bフェデレーション）、レガシーシステム	OIDCに比べて構成が複雑で、署名検証やオプションの暗号化のためにX.509証明書の管理（証明書のローテーションや有効期限の監視も含む）が必要
OIDC	JSON Web Token（JWT）	モダンなWebアプリケーション、モバイルアプリケーション、API中心のアプリケーション	よりシンプルで、RESTfulであり、開発者にとって扱いやすい

• OIDCは、OAuth 2.0を基盤としたアイデンティティレイヤーです。IDトークン内のアイデンティティクレームに署名付きJWTを使用し、APIアーキテクチャとの親和性に優れています。新規開発のアプリケーションやインターネット向けアプリケーション、モバイルアプリケーションでは、Authorization Code FlowとPKCEを組み合わせたOIDCの利用が、OAuth 2.0 Security Best Current Practiceで推奨されています。
• SAML 2.0は現在でもB2Bフェデレーションで広く利用されています。特に、Active Directory Federation Services（AD FS）などの顧客のアイデンティティインフラストラクチャと連携する場合によく採用されており、大企業ではSAML対応が必須要件となるケースも少なくありません。

B2B SaaSの環境では、顧客が利用するIdPによって連携の要件が決まるため、アプリケーション側は両方のプロトコルをサポートする必要があるケースが一般的です。

B2B SaaSのマルチテナントSSOでは、アプリケーション（SP）が各顧客組織の独立したIdPとフェデレーションを設定する必要があります。

• テナント固有の設定：アプリケーションは、顧客ごとに固有のIdP設定情報（SAMLの署名証明書やOIDCのクライアントシークレットなど）をセキュアに保存・管理する必要があります。
• ホームレルムディスカバリー（HRD）：アプリケーションは、認証リクエストをどの顧客のIdPに転送するかを判断する必要があります。一般的には、ユーザーのEメールアドレスのドメインや、ログイン前に入力された組織識別子に基づいて認証要求を適切なIdPへ振り分けることで実現されます。
• ジャストインタイム（JIT）プロビジョニング：JITプロビジョニングでは、初回のSSO認証フローの実行時に、IdPから受け取ったクレームを基にして、アプリケーション内にユーザーのローカルアカウントを自動作成します。そのため、顧客企業のユーザーアカウントを手動でプロビジョニングする必要がなくなります。
• 認証後の認可：SSOによる認証が成功した後、アプリケーションは、ロールベースのアクセス制御（RBAC）などの認可ポリシーを適用し、ユーザーがどのリソースにアクセスできるかを決定する必要があります。SSOが担うのはユーザーのアイデンティティ確認であり、アクセス権限の管理はアプリケーション側の認可レイヤーが担います。

SSOは認証を一元化する一方で、リスクも集約します。そのため開発者は、SPをトークン関連の脆弱性から保護できるよう、十分なセキュリティ対策を講じる必要があります。

• 必須のトークン検証：保護されたすべてのAPIエンドポイントで、十分なJWTの検証を実施する必要があります。これには、署名の整合性の検証、expクレームのチェックと、issクレームとaudクレームの確認などがあります。これらのチェックによって、トークンが正当なものであり、自社のアプリケーション向けに発行されたものであることを確認できます。
• セキュアな保管：機密性の高いアクセストークンやリフレッシュトークンを、localStorageやsessionStorageに保存することは避けてください。これらの保存先では、クロスサイトスクリプティング（XSS）攻撃のリスクが高まるためです。シングルページアプリケーションでは、メモリ内ストレージと自動更新の仕組みを利用してください。従来型のWebアプリでは、HttpOnly属性、Secure属性、SameSite属性を設定したCookieを使用してください。
• OIDCにおけるPKCE：認可コードの横取り攻撃を軽減するために、モバイルアプリやWebアプリなどすべてのOIDCベースのアプリケーションで、Authorization Code FlowとPKCE（Proof Key for Code Exchange）を組み合わせて使用してください。
• 有効期間の短いトークン：有効期間の短いアクセストークン（最大15～60分）を使用するとともに、リフレッシュトークンのローテーションを実装してください。リフレッシュのたびに新しいリフレッシュトークンを発行し、以前のトークンを無効化することで、トークンの盗難を即座に検知できるようになります。
• セッションIDの固定化攻撃の防止：サービスプロバイダーは、IdPから受け取ったトークンの検証後、直ちに自身のローカルセッションIDを再生成して、セッションIDの固定化攻撃を防ぐ必要があります。なお、この対策の責任はIdPではなくSPにあります。

SPセッションの不適切な管理

サービスプロバイダーは多くの場合、IdPから受け取ったトークンを正しく検証しているものの、自社のアプリケーションセッションの保護が不十分なケースが少なくありません。SSOによる認証後、SPは適切なセッションタイムアウト、CSRF対策、セキュアなCookie設定を備えたセッションを確立する必要があります。

不適切なトークン有効期間ポリシー

有効期間の長いIdPセッション（24時間以上など）を再認証なしで許可するとリスクが高まります。適切なセッションタイムアウトを設定するとともに、リスクの高い操作を実行する前には、ステップアップ認証を用いて再認証を求めるようにしてください。

ログアウト処理の複雑さを軽視すること

SSOログアウトでは、IdPと利用中の全SPとの連携が必要です。実装が不完全な場合、「ログアウト」した後も一部のアプリケーションでセッションが有効なままとなりますが、利用者は「ログアウトしたので安全だ」と誤解することになります。そのため、一元的なログアウト機能（シングルログアウト：SLO）を実装するか、セッションの動作について利用者に明確に説明する必要があります。

検証せずにIdPのアサーションを信頼すること

サービスプロバイダーは、すべてのトークンについて、署名、有効期限、対象者（audience）、発行者（issuer）のクレームを検証する必要があります。「自社のIdPから発行されたものだ」という理由で検証を省略すると脆弱性につながります。攻撃者は、そのような不備を利用して、トークンの偽造やリプレイ攻撃を仕掛ける可能性があります。

SSOはモバイルアプリケーションでどのように機能しますか？

モバイル向けのSSOでは、Authorization Code FlowとPKCEを組み合わせたOIDCプロトコルを利用します。また、埋め込みのWebViewではなく、システムブラウザ（iOSのASWebAuthenticationSessionやAndroidのCustom Tabs）を利用する必要があります。システムブラウザは、同じ認証ドメインを利用するアプリケーション間でIdPのセッションCookieを共有できるため、真のSSOを実現できます。ただし、セッション共有の動作はプラットフォームやプライバシー設定によって異なります。たとえば、iOSのASWebAuthenticationSessionはデフォルトで一時的なセッションを作成するため、セッションを保持するにはユーザーによる明示的な許可が必要です。一方、埋め込みのWebViewはシステムのCookieストアにアクセスできないため、SSOの仕組みが機能しません。

SSOは多要素認証（MFA）の代わりになりますか？

いいえ。SSOは認証を行う場所を決定する仕組みであり、認証を中央のIdPに集約します。一方、MFAは認証の強度を決定します。そのため、併用が推奨されます。中央のIdPでMFAを必須化することで、一度の強力な認証によって、連携する全アプリケーションへのアクセスを保護できます。

SSOが適していないのはどのような場合ですか？

小規模な消費者向けアプリケーションやシンプルなコンテンツサイトでは、SSOの複雑さやインフラの要件が、そのメリットを上回るケースが少なくありません。一方でSSOは、IT管理が一元化されたエンタープライズ環境で、ユーザーが複数の保護されたリソースに対して継続的にアクセスする必要がある場合に、特に高い価値を発揮します。

SSOをゼロから実装すること、とりわけSAMLとOIDCの両方に対応することは容易ではありません。Auth0のような専用のアイデンティティプラットフォームを利用すれば、認証プロトコルの複雑さやセッション管理への対応、セキュリティ堅牢化を効率的に進められるため、開発者はアプリケーション本来の機能開発に集中できるようになります。

アイデンティティとアクセス管理に関連するその他のトピックについては、「IAM入門」シリーズをご覧ください。

詳細を見る