> ## Documentation Index > Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # シングルサインオン > Auth0 シングルサインオン（SSO）を使用すると、ユーザーは一度認証するだけで、資格情報を再入力せずに同じテナント内のすべてのアプリケーションにアクセスできます。シングルサインオン (SSO) とは、ユーザーが1つのアプリケーションにログインすると、そのユーザーが使用しているプラットフォーム、技術、ドメインに関係なく、他のアプリケーションにも自動的にサインインされる仕組みです。ユーザーは一度サインインするだけでよいため、この機能はシングルサインオンと呼ばれます。たとえば、Gmail のような Google のサービスにログインすると、YouTube、AdSense、Google Analytics、その他の Google アプリにも自動的に認証されます。同様に、Gmail やその他の Google アプリからログアウトすると、すべてのアプリから自動的にログアウトされます。これはシングルログアウトと呼ばれます。 SSO により、ユーザーはアプリケーションやサービスをシームレスに利用できます。アプリケーションやサービスごとに別々の資格情報を覚える必要はなく、一度ログインするだけで、関連するアプリケーション一式にアクセスできます。ユーザーが認証を必要とするドメインにアクセスすると、認証ドメインにリダイレクトされ、そこでログインを求められる場合があります。ユーザーがすでに認証ドメインにログインしていれば、再度サインインしなくても、すぐに元のドメインへリダイレクトされます。

## 仕組み

シングルサインオンとシングルログアウトは、[セッション](/docs/ja-jp/manage-users/sessions)を利用することで実現できます。SSO では、ユーザーに対して最大 3 種類の異なるセッションが存在する場合があります。 * アプリケーションで維持されるローカルセッション * SSO が有効な場合の認可サーバーセッション * ユーザーがIDプロバイダー (Google、Facebook、またはエンタープライズSAML IDプロバイダーなど) 経由でログインすることを選択した場合のIDプロバイダー (IdP) セッション SSO では、中央のドメインが認証を行い、その後ほかのドメインとセッションを共有します。セッションの共有方法は SSO プロトコルによって異なる場合がありますが、基本的な考え方は同じです。たとえば、認証ドメインは署名付きの[JSON Web Token (JWT)](/docs/ja-jp/secure/tokens/json-web-tokens) (JSON Web Encryption (JWE) を使用して暗号化されたもの) を生成できます。これには、認証を必要とするほかの任意のドメインでユーザーを識別するために必要な情報がすべて含まれています。このトークンはクライアントに渡されますが、署名されているため、クライアントがこれを改変することはできません。このトークンはリダイレクトによって元のドメインに渡すことができ、認証ドメインやほかのドメインでユーザーの識別に使用できます。 Auth0 でシングルサインオン (SSO) を実装する最も簡単で安全な方法は、認証に [Universal Login](/docs/ja-jp/authenticate/login/auth0-universal-login) を使用することです。実際、現在ネイティブプラットフォーム (iOS や Android など) で SSO が可能なのは、アプリケーションが Universal Login を使用している場合に限られます。[Swift](/docs/ja-jp/quickstart/native/ios-swift) と [Android](/docs/ja-jp/quickstart/native/ios-swift) のクイックスタートには、Universal Login の使用例がいくつかあります。アプリケーションで Universal Login を使用できない場合は、埋め込み認証の詳細について以下を参照してください。 * [Lock](/docs/ja-jp/libraries/lock/lock-api-reference) * [Auth0.js](/docs/ja-jp/libraries/auth0js) シングルサインオンで [Passwordless](/docs/ja-jp/authenticate/passwordless/passwordless-with-universal-login) を使用している場合、接続パラメータ `sms` と `email` では既存の Auth0 セッションは利用されず、ユーザーはログインを求められます。 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 内でユーザーの[サイレント認証](/docs/ja-jp/authenticate/login/configure-silent-authentication)が試みられます。認証が成功するかどうかで、ユーザーに有効なSSO Cookie があるかどうかを判断できます。

## プロトコル

### SAML と WS-Federation

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

### OpenID Connect

OpenID Connect (OIDC) は、一般消費者向けの SSO 実装で広く使われている認証プロトコルです。OIDC プロトコルは、JSON Web Tokens と一元的な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](/docs/ja-jp/authenticate/single-sign-on/inbound-single-sign-on) では、Auth0 が SSO のサービスプロバイダー (SP) になります。ユーザーがアプリケーションにログインすると、次のような流れになります。 1. アプリケーションは、1 つ以上の外部IDプロバイダーをユーザーに提示します。 2. ユーザーは認証に使用するIDプロバイダーを選択してログインします。 3. 認証に成功すると、ユーザーはアプリケーションに戻ります。 Auth0 での SP 主導の SSO は、接続によって処理されます。

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

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

## ユースケース

### 企業間

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

### Business to Consumer CIAM

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