> ## 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.

# シングルサインオン

> シングルサインオン（SSO）とは何か、またその仕組みを説明します。

<Tooltip tip="シングルサインオン（SSO）: ユーザーが1つのアプリケーションにログインすると、他のアプリケーションにも自動的にログインできるようになるサービス。" cta="用語集を見る" href="/ja/docs/glossary?term=Single+Sign-on">シングルサインオン</Tooltip> (SSO) とは、ユーザーが1つのアプリケーションにログインすると、ユーザーが利用しているプラットフォーム、テクノロジー、ドメインに関係なく、他のアプリケーションにも自動的にサインインされる仕組みです。ユーザーがサインインするのは1回だけであることが、この機能名の由来です (Single Sign-on) 。

たとえば、Gmail などの Google サービスにログインすると、YouTube、AdSense、Google Analytics、その他の Google アプリにも自動的に認証されます。同様に、Gmail や他の Google アプリからログアウトすると、すべてのアプリから自動的にログアウトされます。これはシングルログアウトと呼ばれます。

SSO は、ユーザーがアプリケーションやサービスを利用する際にシームレスな体験を提供します。各アプリケーションやサービスごとに別々の認証情報を覚える必要はなく、1回ログインするだけで一連のアプリケーションすべてにアクセスできます。

ユーザーが認証を必要とするドメインにアクセスすると、認証ドメインにリダイレクトされ、ログインを求められる場合があります。ユーザーがすでに認証ドメインでログインしていれば、再度サインインすることなく、元のドメインにすぐにリダイレクトされます。

<div id="how-it-works">
  ## 仕組み
</div>

[sessions](/ja/docs/manage-users/sessions) を使用すると、シングルサインオンとシングルログアウトを実現できます。SSO を使用するユーザーには、最大 3 種類の異なるセッションが存在する場合があります。

* アプリケーションによって維持されるローカルセッション
* SSO が有効な場合の <Tooltip tip="認可サーバー: ユーザーのアクセス範囲の定義に関与する集中型サーバー。たとえば、認可サーバーはユーザーが利用できるデータ、タスク、機能を制御できます。" cta="用語集を表示" href="/ja/docs/glossary?term=Authorization+Server">認可サーバー</Tooltip> セッション
* ユーザーが <Tooltip tip="IDプロバイダー（IdP）: デジタルIDを保存および管理するサービス。" cta="用語集を表示" href="/ja/docs/glossary?term=Identity+Provider+%28IdP%29">IDプロバイダー (IdP) </Tooltip> 経由でログインすることを選択した場合の <Tooltip tip="IDプロバイダー（IdP）: デジタルIDを保存および管理するサービス。" cta="用語集を表示" href="/ja/docs/glossary?term=Identity+Provider">IDプロバイダー</Tooltip> セッション (Google、Facebook、またはエンタープライズ <Tooltip tip="Security Assertion Markup Language (SAML): パスワードなしで 2 者間が認証情報を交換できるようにする標準化されたプロトコル。" cta="用語集を表示" href="/ja/docs/glossary?term=SAML">SAML</Tooltip> IDプロバイダーなど)

SSO では、中央のドメインが認証を実行し、その後ほかのドメインとセッションを共有します。セッションの共有方法は SSO プロトコルによって異なる場合がありますが、基本的な考え方は同じです。

たとえば、認証ドメインは、認証が必要なほかのドメインでユーザーを識別するために必要なすべての情報を含む、署名付きの [JSON Web Token (JWT)](/ja/docs/secure/tokens/json-web-tokens) (JSON Web Encryption (JWE) を使用して暗号化) を生成する場合があります。このトークンはクライアントに渡されますが、署名されているため、クライアントがこれを変更することはできません。このトークンはリダイレクトによって元のドメインに渡され、認証ドメインやほかのドメインでユーザーの識別に使用できます。

<div id="sso-with-universal-login">
  ## Universal Login での SSO
</div>

Auth0 でシングルサインオン (SSO) を実装する最も簡単で安全な方法は、認証に [Universal Login](/ja/docs/authenticate/login/auth0-universal-login) を使用することです。実際、現時点では、アプリケーションで <Tooltip tip="Universal Login: アプリケーションはユーザーの本人確認を行うために、Auth0 の認可サーバーでホストされる Universal Login にリダイレクトされます。" cta="用語集を見る" href="/ja/docs/glossary?term=Universal+Login">Universal Login</Tooltip> を使用している場合にのみ、ネイティブプラットフォーム (iOS や Android など) で SSO を利用できます。[Swift](/ja/docs/quickstart/native/ios-swift) および [Android](/ja/docs/quickstart/native/ios-swift) のクイックスタートには、Universal Login の使用例がいくつか掲載されています。

アプリケーションで Universal Login を使用できない場合は、埋め込み認証の詳細について以下を参照してください。

* [Lock](/ja/docs/libraries/lock/lock-api-reference)
* [Auth0.js](/ja/docs/libraries/auth0js)

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  シングルサインオンで [Passwordless](/ja/docs/authenticate/passwordless/passwordless-with-universal-login) を使用している場合、接続パラメーター `sms` と `email` では既存の Auth0 セッションは利用されないため、ユーザーはログインを求められます。
</Callout>

<div id="sso-on-first-login">
  ### 初回ログイン時の SSO
</div>

Auth0 で SSO を使用する場合、**Central Service** は Auth0 の <Tooltip tip="認可サーバー: ユーザーがアクセスできる範囲の定義に関与する集中管理型サーバーです。たとえば、認可サーバーはユーザーが利用できるデータ、タスク、機能を制御できます。" cta="用語集を見る" href="/ja/docs/glossary?term=Authorization+Server">認可サーバー</Tooltip> です。

ユーザーが初めてログインする際の SSO フローの例を見てみましょう。

1. アプリケーションはユーザーをログインページにリダイレクトします。
2. Auth0 は、既存の SSO cookie があるかどうかを確認します。
3. ユーザーがログインページを訪れるのは今回が初めてで、SSO cookie も存在しないため、設定したいずれかの接続を使用してログインするよう求められます。

   <Frame>
     <img src="https://mintcdn.com/translations/6GE5Z24GDCZehiJ9/docs/images/cdy7uua7fh8z/6m01sxT4xI0oUC6ox3vb4Z/ca72f1208d952a9a43f24f425d360e48/Screenshot_2024-07-11_at_11.57.33.png?fit=max&auto=format&n=6GE5Z24GDCZehiJ9&q=85&s=64c63b7963ed2b26118bf3e69231c7a6" alt="timesheets アプリケーションのログイン画面の例" width="283" height="527" data-path="docs/images/cdy7uua7fh8z/6m01sxT4xI0oUC6ox3vb4Z/ca72f1208d952a9a43f24f425d360e48/Screenshot_2024-07-11_at_11.57.33.png" />
   </Frame>
4. ユーザーがログインすると、Auth0 は SSO cookie を設定し、ユーザーをアプリケーションにリダイレクトするとともに、ユーザーの識別情報を含む IDトークン を返します。

<div id="sso-on-subsequent-logins">
  ### 2回目以降のログインでの SSO
</div>

ユーザーが再度 Web サイトを訪問したときの SSO フローの例を見てみましょう。

1. アプリケーションがユーザーをログインページにリダイレクトします。
2. Auth0 は既存の SSO Cookie があるかどうかを確認します。
3. Auth0 は SSO Cookie を見つけ、必要に応じて更新します。ログイン画面は表示されません。
4. Auth0 はユーザーをアプリケーションにリダイレクトし、ユーザーの識別情報を含む IDトークンを返します。

<div id="check-users-sso-status">
  ### ユーザーの SSO 状態を確認する
</div>

アプリケーションからユーザーの SSO 状態を確認するには、`auth0.js` SDK の `checkSession` メソッドを呼び出します。これにより、iframe 内でユーザーの[サイレント認証](/ja/docs/authenticate/login/configure-silent-authentication)が試行されます。認証が成功したかどうかで、ユーザーにアクティブな SSO Cookie があるかどうかを判断できます。

<div id="protocols">
  ## プロトコル
</div>

<div id="saml-and-ws-federation">
  ### SAML と WS-Federation
</div>

Security Assertion Markup Language (SAML) と Web Services Federation (<Tooltip tip="Web Service Federation（WS-Fed）: ドメイン間でユーザーアイデンティティを管理するためのプロトコル。" cta="用語集を表示" href="/ja/docs/glossary?term=WS-Fed">WS-Fed</Tooltip>) は、どちらも SSO の実装で広く使用されている[プロトコル](/ja/docs/authenticate/protocols)です。SAML と WS-Fed はいずれも、認可および認証に関するデータを XML 形式でやり取りします。このやり取りの主な要素は、ユーザー、IDプロバイダー、サービスプロバイダーです。

SAML または WS-Fed では、次のように動作します。

1. ユーザーがサービスプロバイダーにリソースを要求します。
2. サービスプロバイダーは、ユーザーにそのリソースへのアクセスを許可すべきかどうかを IDプロバイダーに確認します。
3. IDプロバイダーはユーザーのアイデンティティを検証し、有効であれば、そのユーザーにアクセスを許可すべきであることをサービスプロバイダーに表明します。

<div id="openid-connect">
  ### OpenID Connect
</div>

<Tooltip tip="OpenID: アプリケーションがログイン情報を収集・保存することなく、ユーザーの本人確認を行えるようにする認証のオープン標準です。" cta="用語集を表示" href="/ja/docs/glossary?term=OpenID">OpenID</Tooltip> Connect (OIDC) は、一般的にコンシューマー向けSSOの実装で使用される認証プロトコルです。OIDCプロトコルでは、<Tooltip tip="JSON Web Token（JWT）: 2者間でクレームを安全に表現するために使用される標準的なIDトークン形式（多くの場合、アクセストークン形式としても使用されます）。" cta="用語集を表示" href="/ja/docs/glossary?term=JSON+Web+Tokens">JSON Web Tokens</Tooltip>と中央のIDプロバイダーを通じて認証を処理します。

OIDCでは、次の流れで処理されます。

1. ユーザーがアプリケーションへのアクセスを要求します。
2. アプリケーションは、認証のためにユーザーをIDプロバイダーにリダイレクトします。
3. IDプロバイダーがユーザーを認証し、成功すると、アプリケーションへのデータアクセスを許可するようユーザーに求めます。
4. アクセスが許可されると、IDプロバイダーはIDトークンを生成します。このIDトークンには、アプリケーションが利用できるユーザーの識別情報が含まれます。
5. IDプロバイダーはユーザーをアプリケーションに戻します。

<div id="adldap">
  ### AD/LDAP
</div>

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

<div id="service-provider-initiated-sso">
  ## サービスプロバイダー主導の SSO
</div>

[サービスプロバイダー主導の SSO](/ja/docs/authenticate/single-sign-on/inbound-single-sign-on) では、Auth0 が SSO のサービスプロバイダー (SP) です。

ユーザーがアプリケーションにログインすると、次のようになります。

1. アプリケーションは、1 つ以上の外部 IDプロバイダーをユーザーに提示します。
2. ユーザーは認証に使用する IDプロバイダーを選択してログインします。
3. 認証に成功すると、ユーザーはアプリケーションに戻ります。

Auth0 の SP 主導 SSO は、接続によって処理されます。

<div id="identity-provider-initiated-sso">
  ## IDプロバイダー主導のSSO
</div>

[IDプロバイダー主導のSSO](/ja/docs/authenticate/single-sign-on/outbound-single-sign-on) では、サードパーティのIDプロバイダー (IdP) がSSOプロバイダーとなります。

ユーザーがアプリケーションにログインする際:

1. アプリケーションはユーザーをIDプロバイダーにリダイレクトします。
2. サードパーティのIDプロバイダーが認証と認可を行います。
3. 認証に成功すると、ユーザーはアプリケーションに戻されます。

IdP 主導の SSO 実装を計画する際は、Auth0 の [SSO Dashboard Extension](/ja/docs/customize/extensions/single-sign-on-dashboard-extension/create-sso-dashboard-application) を使用することもできます。これにより、複数のエンタープライズアプリケーションを一覧表示し、SSO を有効にできるダッシュボードを作成できます。作成したダッシュボードをユーザーに提示することで、そこからログインできるようになります。

<div id="use-cases">
  ## ユースケース
</div>

<div id="business-to-business">
  ### 企業間 (B2B)
</div>

B2B のシナリオでは、SSO によってアプリケーションをエンタープライズ向けに提供しやすくなります。Auth0 を使用すると、アプリケーションで Active Directory (AD) 、Lightweight Directory Access Protocol (LDAP) 、Ping、SAML など、一般的なエンタープライズ フェデレーションのシナリオをサポートできます。これにより、パートナーやエンタープライズ顧客は、使い慣れたエンタープライズ ID 技術を使用してログインできます。

* [導入事例: O'Reilly](https://auth0.com/case-studies/oreilly)

<div id="business-to-consumer-ciam">
  ### B2C 向け CIAM
</div>

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

* [導入事例: Giving Compass](https://auth0.com/case-studies/giving-compass)