> ## Documentation Index > Fetch the complete documentation index at: https://docs-dev-docs-event-stream-action-templates.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # 中央集中型ユニバーサルログインと埋め込みログイン > 中央集中型のユニバーサルログインと埋め込みログインの違いについて説明します。 アプリケーションに認証エクスペリエンスを設計する際には、ログインフローに **ユニバーサル** ログインを使用するか **埋め込み** ログインを使用するかを選択する必要があります。 * **ユニバーサルログイン** を使用すると、ログインしようとしたユーザーは中央ドメインにリダイレクトされ、そこで認証が行われてから、アプリにリダイレクトで戻されます。この例としては、G Suiteが挙げられます。アクセスしようとするサービス（GmailやGoogleカレンダー、Google Docsなど）にかかわらず、ログインしていないユーザーは`https://accounts.google.com`にリダイレクトされ、ログインに成功したら元のアプリにリダイレクトで戻されます。 * 一方、 **埋め込みログイン** フローはユーザーを中央の場所にリダイレクトしません。ログインウィジェットは、ユーザーを別のドメインにリダイレクトすることなく、同じページで機能します。そして、認証のために資格情報が認証プロバイダーへ送られます。Webアプリでは、これはクロスオリジン要求になります。 ## 長所と短所 | 機能 | 一元化 | 埋め込み | | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **シングルサインオン** | モバイルアプリを使用する場合は、ユニバーサルログインを使わない限り、SSOを利用できません。Webアプリの場合は、利用できますが、最も安全な方法はクッキーが同一オリジンからになるように中央サービスを使用することになります。 | 埋め込みログインでは、１つのオリジンから提供されるアプリケーションでユーザー資格情報を収集し、それを別のオリジンに送信する必要があるため、フィッシング攻撃の可能性を含み、特定のセキュリティ上の脆弱性が生じる可能性があります。 | | **一貫性とメンテナンス** | 認可サーバー（ユーザーをログインしたドメイン）がすべてのログインページを所有しているため、管理が簡単であり、ページの一貫性と安全性が向上します。またアプリ間で単一のログインページを使用することができるため、ユーザーは個々のアプリではなく、一括されたシステムにログインしているという印象を持ちます。 | アプリが複数ある場合は、複数のログインページを実装する必要があります。また、これらのページを維持および管理する必要があります。手間がかかることに加えて、一貫性が損なわれる可能性があり、ユーザーエクスペリエンスに悪影響を及ぼします。さらに、埋め込みログインでは、クロスオリジン攻撃ベクトルの危険性を管理する必要があります。 | | **機能の管理** | Dashboardを使用して、すべてのアプリでMFAなどの機能をオンまたはオフにできます。 | アプリケーションごとに個別に行う必要があります。 | | **ユーザーエクスペリエンス** | ログインのために別のサブドメインにリダイレクトします。 | ログインのために別のサブドメインにリダイレクトしません。 | | **モバイルアプリおよびセキュリティ** | [ネイティブアプリに関するOAuth 2.0の現行のベストプラクティスの文書](https://www.rfc-editor.org/rfc/rfc8252.txt)によると、ネイティブアプリケーションは外部ユーザーエージェントのみ（ブラウザーなど）を認証フローに使用するべきだとされています。ブラウザーを使用してネイティブアプリの認証要求を行うことは、セキュリティを向上し、正しいドメインで資格情報を入力しているという自信をユーザーに与えます。また、ユーザーの現在の認証状態の使用が可能になるため、シングルサインオンを可能にします。 | 埋め込まれたユーザーエージェントは、サードパーティーにとって安全でないとみなされるため、実装されてはなりません。ネイティブログインでは、悪意のあるアプリが識別子/パスワードまたはトークンのためにユーザーにフィッシング詐欺を試みる可能性があります。また、モバイルアプリがネイティブログインを使用している場合、ユーザーはアプリごとに資格情報を入力する必要があるため、SSOの使用は不可能です。 | ## セキュリティリスク * ユニバーサルログインは埋め込みログインよりも安全です。認証が同じドメインで処理されるため、クロスオリジン要求を必要としません。クロスオリジン認証は本質的により危険です。1つのオリジンから提供されるアプリケーションでユーザー資格情報を収集し、それを別のオリジンに送信すると、一定のセキュリティ上の脆弱性が生じる可能性があります。フィッシング攻撃の可能性が高くなり、バケツリレー攻撃も受けやすくなります。ユニバーサルログインにはオリジン間の情報交換がないため、クロスオリジンに関する懸念が解消されます。詳細については、「[一般的なサイバーセキュリティの脅威を防止する](/docs/ja-jp/secure/security-guidance/prevent-threats)」をお読みください。 * 埋め込みのユーザーエージェントはサードパーティにとって危険性が高く、これは認可サーバー自体にも当てはまります。埋め込みログインが使用されると、アプリは認可付与とユーザーの認証資格情報の両方を利用します。その結果、このデータが記録や悪意のある使用に対して脆弱なままになります。信頼できるアプリであっても、認可付与やユーザーの資格情報に対してアクセスを許可することは不必要です。これは、最小特権の原則（PoLP）に反し、攻撃の可能性を高める行為です。 GoogleではOAuthの実装について、埋め込み方式の対応が中止されています。さらに、[Internet Engineering Task Force（IETF）](https://www.ietf.org/)によると、主にユーザーのブラウザーなど、外部のユーザーエージェントを介してのみ、ネイティブアプリから認可要求が行われるべきだということです。ネイティブアプリがブラウザーを通して認可要求を行うことによって、セキュリティが向上します。埋め込みのエージェントを使用すれば、アプリがOAuthの認可付与だけでなく、ユーザーの資格情報にもアクセスできるため、このデータが記録や悪意のある使用に対して脆弱なままになります。 他にも役立つリソースとして、「[ネイティブアプリのOAuthインタラクションを最新にしてユーザビリティとセキュリティを向上する](https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html)」（[https://developers.googleblog.com](https://developers.googleblog.com)）があります。 ## Auth0を使ったユニバーサルログイン ほとんどの場合では、Auth0が認証要求でログインページを表示するという、ユニバーサルログイン方策の使用が推奨されます。ログインページはDashboardを使ってカスタマイズできます。 Auth0のカスタムドメインを使用すると、ログインページとアプリ全体に同じドメインを維持することができます。ドメインが変わらないため、ユーザーが意識することなく、ログインページにリダイレクトできます。詳細については、「[カスタムドメイン](/docs/ja-jp/customize/custom-domains)」をお読みください。 アプリが認証要求をトリガーすると必ず、ユーザーは認証のためにログインページにリダイレクトされます。この際に、Cookieが作成されます。その後の認証要求では、Auth0はこのCookieを確認します。このCookieがある場合には、ユーザーはログインページにリダイレクトされません。実際にログインが必要になときに限り、ログインページがユーザーに表示されます。SSOを実装するには、これが最も手軽な方法です。 受信する認証要求が外部のIDプロバイダー（Facebookなど）を使用する場合には、ログインページが表示されないことに注意してください。その代わりに、Auth0はユーザーをIDプロバイダーのログインページへ送ります。 カスタムログインページは、[GitHub](https://marketplace.auth0.com/integrations/github-actions)、[Bitbucket](https://marketplace.auth0.com/integrations/bitbucket-pipeline)、[GitLab](https://marketplace.auth0.com/integrations/gitlab-pipeline)、[Microsoft Azure](https://marketplace.auth0.com/integrations/azure-pipeline)などの外部リポジトリから導入することができます。 Auth0を使用する場合には、ユニバーサルログインの使用をお勧めします。まず第一に重要なのは、セキュリティです。埋め込みログインではなく、Auth0のユニバーサルログインをアプリケーションに使用することは、シームレスなクロスサイトリクエストフォージェリ（CSRF）対策になります。サードパーティのなりすましやセッションの乗っ取りから保護するのに役立ちます。 ## Auth0を使った埋め込みログイン Auth0を使ったWebアプリでの埋め込みログインには、クロスオリジン認証が使用されます（詳細については、「[クロスオリジン認証](/docs/ja-jp/authenticate/login/cross-origin-authentication)」をお読みください）。サードパーティCookieを使用すると、異なるオリジン間で認証トランザクションを安全に行うことができます。これはネイティブアプリには該当しません。ネイティブアプリは標準のOAuth 2.0 `/token`エンドポイントを利用します。サードパーティのクッキーについては、「[追跡とプライバシー：サードパーティークッキー](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#Third-party_cookies)」（[https://developer.mozilla.org](https://developer.mozilla.org)）をお読みください。 Auth0はクロスオリジン認証を推奨しませんが、使用するのであれば、IDとパスワードを使用してディレクトリに対する認証を行う場合だけにしてください。ソーシャルIdPやエンタープライズフェデレーションは異なるメカニズムを使用しており、OpenIDConnect（OIDC）やSAMLなどの標準プロトコルを介してリダイレクトします。さらに、クロスオリジン認証は、Web上の埋め込み型ログイン（Lockまたはauth0.jsを使用）にのみ適用されます。埋め込み型ログインを使用するネイティブアプリケーションは、標準のOAuth 2.0トークンエンドポイントを利用します。 また、カスタムドメインを有効にしている場合、エンドユーザーはサードパーティのCookieに対応しているブラウザーを使用しなければなりません。そうしないと、一部のブラウザーではクロスオリジン認証が失敗します。この制限は、従来型のID/パスワードのデータベース接続とパスワードレスのデータベース接続の両方に適用されます。 ## もっと詳しく * [一般的なサイバーセキュリティの脅威を防止する](/docs/ja-jp/secure/security-guidance/prevent-threats) * [カスタムドメインのトラブルシューティング](/docs/ja-jp/troubleshoot/integration-extensibility-issues/troubleshoot-custom-domains)