Skip to main content
(SSO) とは、ユーザーが1つのアプリケーションにログインすると、そのユーザーが使用しているプラットフォーム、技術、ドメインに関係なく、他のアプリケーションにも自動的にサインインされる仕組みです。ユーザーは一度サインインするだけでよいため、この機能はシングルサインオンと呼ばれます。 たとえば、Gmail のような Google のサービスにログインすると、YouTube、AdSense、Google Analytics、その他の Google アプリにも自動的に認証されます。同様に、Gmail やその他の Google アプリからログアウトすると、すべてのアプリから自動的にログアウトされます。これはシングルログアウトと呼ばれます。 SSO により、ユーザーはアプリケーションやサービスをシームレスに利用できます。アプリケーションやサービスごとに別々の資格情報を覚える必要はなく、一度ログインするだけで、関連するアプリケーション一式にアクセスできます。 ユーザーが認証を必要とするドメインにアクセスすると、認証ドメインにリダイレクトされ、そこでログインを求められる場合があります。ユーザーがすでに認証ドメインにログインしていれば、再度サインインしなくても、すぐに元のドメインへリダイレクトされます。

​
利点

Auth0 の SSO を使用する理由
  • 統合アクセス: ユーザーは一度認証すれば、資格情報を再入力することなく、関連するすべての独立したアプリケーションにアクセスできます。
  • 一元化されたセッション: Auth0 は中央のドメインとブラウザー Cookie を使用して、複数のアプリケーション間で認証状態を共有します。
  • Universal Login: Auth0 の Universal Login を利用すれば、あらゆるプラットフォームで SSO を安全に実装できます。

​
仕組み

シングルサインオンとシングルログアウトは、セッションを利用することで実現できます。SSO では、ユーザーに対して最大 3 種類の異なるセッションが存在する場合があります。
  • アプリケーションで維持されるローカルセッション
  • SSO が有効な場合のセッション
  • ユーザーが (Google、Facebook、またはエンタープライズ IDプロバイダーなど) 経由でログインすることを選択した場合の セッション
SSO では、中央のドメインが認証を行い、その後ほかのドメインとセッションを共有します。セッションの共有方法は SSO プロトコルによって異なる場合がありますが、基本的な考え方は同じです。 たとえば、認証ドメインは署名付きのJSON Web Token (JWT) (JSON Web Encryption (JWE) を使用して暗号化されたもの) を生成できます。これには、認証を必要とするほかの任意のドメインでユーザーを識別するために必要な情報がすべて含まれています。このトークンはクライアントに渡されますが、署名されているため、クライアントがこれを改変することはできません。このトークンはリダイレクトによって元のドメインに渡すことができ、認証ドメインやほかのドメインでユーザーの識別に使用できます。

​
Universal Login での SSO

Auth0 でシングルサインオン (SSO) を実装する最も簡単で安全な方法は、認証に Universal Login を使用することです。実際、現在ネイティブプラットフォーム (iOS や Android など) で SSO が可能なのは、アプリケーションが を使用している場合に限られます。Swift と Android のクイックスタートには、Universal Login の使用例がいくつかあります。 アプリケーションで Universal Login を使用できない場合は、埋め込み認証の詳細について以下を参照してください。
シングルサインオンで Passwordless を使用している場合、接続パラメータ sms と email では既存の Auth0 セッションは利用されず、ユーザーはログインを求められます。

​
初回ログイン時の SSO

Auth0 で SSO を利用する場合、Central Service は Auth0 のです。 ユーザーが初めてログインする場合の SSO フローの例を見てみましょう。
  1. アプリケーションがユーザーをログインページにリダイレクトします。
  2. Auth0 は既存の SSO Cookie があるかどうかを確認します。
  3. ユーザーがログインページにアクセスするのは今回が初めてで、SSO Cookie も存在しないため、設定済みのいずれかの接続を使用してログインするよう求められます。
    タイムシートアプリケーションのログイン画面の例
  4. ユーザーがログインすると、Auth0 は SSO Cookie を設定し、ユーザーをアプリケーションにリダイレクトしたうえで、ユーザーのアイデンティティ情報を含む ID トークンを返します。

​
以降のログイン時の SSO

ユーザーが再度 Web サイトを訪問した際の SSO フローの例を見てみましょう。
  1. アプリケーションがユーザーをログインページにリダイレクトします。
  2. Auth0 は既存の SSO Cookie があるかどうかを確認します。
  3. Auth0 は SSO Cookie を検出し、必要に応じて更新します。ログイン画面は表示されません。
  4. Auth0 はユーザーをアプリケーションにリダイレクトし、ユーザーのアイデンティティ情報を含む ID トークンを返します。

​
ユーザーのSSOステータスを確認する

アプリケーションからユーザーのSSOステータスを確認するには、auth0.js SDK の checkSession メソッドを呼び出します。これにより、iframe 内でユーザーのサイレント認証が試みられます。認証が成功するかどうかで、ユーザーに有効なSSO Cookie があるかどうかを判断できます。

​
プロトコル

​
SAML と WS-Federation

Security Assertion Markup Language (SAML) と Web Services Federation () はどちらも、SSO の実装で広く使われているプロトコルです。SAML と WS-Fed はどちらも、認可および認証に関するデータを XML 形式でやり取りします。このやり取りの主な当事者は、ユーザー、IDプロバイダー、サービスプロバイダーです。 SAML または WS-Fed では、次のような流れになります。
  1. ユーザーがサービスプロバイダーにリソースへのアクセスを要求します。
  2. サービスプロバイダーは、ユーザーにそのリソースへのアクセスを許可すべきかどうかを、IDプロバイダーに確認します。
  3. IDプロバイダーはユーザーを認証し、有効であれば、そのユーザーにアクセスを許可すべきであることをサービスプロバイダーに通知します。

​
OpenID Connect

Connect (OIDC) は、一般消費者向けの SSO 実装で広く使われている認証プロトコルです。OIDC プロトコルは、 と一元的なIDプロバイダーを通じて認証を処理します。 OIDC では、
  1. ユーザーがアプリケーションへのアクセスを要求します。
  2. アプリケーションは、認証のためにユーザーをIDプロバイダーへリダイレクトします。
  3. IDプロバイダーがユーザーを認証し、成功すると、アプリケーションによるデータへのアクセスを許可するようユーザーに求めます。
  4. アクセスが許可されると、IDプロバイダーは ID トークンを生成します。これには、アプリケーションが利用するユーザーのアイデンティティ情報が含まれます。
  5. IDプロバイダーはユーザーをアプリケーションに戻します。

​
AD/LDAP

Lightweight Directory Access Protocol (LDAP) は、複数のアプリケーションで共有できる資格情報のディレクトリにアクセスするためのアプリケーションプロトコルで、一般的にイントラネットで利用されます。Active Directory (AD) と組み合わせると、LDAPはユーザーのアイデンティティを一元的に管理する場所を提供するため、アプリケーションはLDAP/ADサーバーに認証リクエストを送信します。LDAPプロトコルでは、LDAP Data Interchange Format (LDIF) で情報をやり取りします。

​
サービスプロバイダー主導のSSO

サービスプロバイダー主導のSSO では、Auth0 が SSO のサービスプロバイダー (SP) になります。 ユーザーがアプリケーションにログインすると、次のような流れになります。
  1. アプリケーションは、1 つ以上の外部IDプロバイダーをユーザーに提示します。
  2. ユーザーは認証に使用するIDプロバイダーを選択してログインします。
  3. 認証に成功すると、ユーザーはアプリケーションに戻ります。
Auth0 での SP 主導の SSO は、接続によって処理されます。

​
アイデンティティプロバイダー起点のSSO

Identity-Provider-initiated SSO では、サードパーティのIDプロバイダー (IdP) が SSO プロバイダーとなります。 ユーザーがアプリケーションにログインすると、次のように処理されます。
  1. アプリケーションがユーザーをIDプロバイダーにリダイレクトします。
  2. サードパーティのIDプロバイダーが認証および認可を行います。
  3. 認証が成功すると、ユーザーはアプリケーションに戻ります。
IdP 起点の SSO 実装を計画する際には、Auth0 の SSO Dashboard 拡張機能 を使用することもできます。これを使うと、SSO を有効にできる複数のエンタープライズ アプリケーションを一覧表示するダッシュボードを作成できます。作成したダッシュボードをユーザーに提示し、そこからログインしてもらいます。

​
サービスプロバイダー主導のSSO とアイデンティティプロバイダー起点のSSO

サービスプロバイダー主導のSSO とアイデンティティプロバイダー起点のSSO のどちらを選ぶかは、主にユーザージャーニーの開始地点と、求められるセキュリティレベルによって決まります。 次のような認証が必要な場合は、サービスプロバイダー主導のSSO を推奨します。
  • 直接アクセス: ユーザーが通常、アプリケーションのログインページをブックマークしたり、ページに直接アクセスしたりする場合に使用します。
    • セキュリティの強化: 特定の「Request ID」を使用してログインリクエストとレスポンスを関連付けるため、クロスサイトリクエストフォージェリ (CSRF) やリプレイ攻撃を防止でき、より安全です。
    • ディープリンク: ログイン後にユーザーをアプリ内の特定のページにリダイレクトする必要がある場合に使用します。
アイデンティティプロバイダー起点のSSO は多くの企業で一般的に使用されており、次のような用途に適しています。
  • 企業ポータル: ユーザーが一日の始まりに、Okta、Microsoft 365、企業イントラネットなどの一元化されたダッシュボードを開き、アイコンを選択してアプリを起動する場合に使用します。
    • ユーザーエクスペリエンスの簡素化: エンドユーザーが最初にアプリケーションのログインページにアクセスする必要がなくなり、すでに認証された状態でアプリケーションにアクセスできます。
    • レガシーシステム: 最新のリダイレクト機能を備えていない古い SAML ベースのエンタープライズシステムと連携する際によく使用されます。

​
ユースケース

​
企業間 SSO

Business to Business (B2B) のシナリオでは、SSO を活用することで、エンタープライズ向けにアプリケーションを提供しやすくなります。Auth0 を使用すると、アプリケーションで Active Directory (AD) 、Lightweight Directory Access Protocol (LDAP) 、Ping、Security Assertion Markup Language (SAML) など、一般的なエンタープライズ フェデレーションのシナリオに対応できます。これにより、パートナーや企業のお客様は、使い慣れたエンタープライズ アイデンティティ技術を使ってログインできます。

​
Business to Consumer CIAM

Business to Consumer (B2C) または Customer Identity Access Management (CIAM) のシナリオでは、SSO により、アプリケーションやサービスにシームレスにアクセスできるようになります。顧客に新たなアカウントの作成を求める代わりに、Google、Facebook、LinkedIn、X、Microsoft などの一般的なソーシャルアイデンティティプロバイダーを使って認証できるようにできます。