- ユニバーサルログイン を使用すると、ログインしようとしたユーザーは中央ドメインにリダイレクトされ、そこで認証が行われてから、アプリにリダイレクトで戻されます。この例としては、G Suiteが挙げられます。アクセスしようとするサービス（GmailやGoogleカレンダー、Google Docsなど）にかかわらず、ログインしていないユーザーは
https://accounts.google.comにリダイレクトされ、ログインに成功したら元のアプリにリダイレクトで戻されます。 - 一方、 埋め込みログイン フローはユーザーを中央の場所にリダイレクトしません。ログインウィジェットは、ユーザーを別のドメインにリダイレクトすることなく、同じページで機能します。そして、認証のために資格情報が認証プロバイダーへ送られます。Webアプリでは、これはクロスオリジン要求になります。
長所と短所
セキュリティリスク
- ユニバーサルログインは埋め込みログインよりも安全です。認証が同じドメインで処理されるため、クロスオリジン要求を必要としません。クロスオリジン認証は本質的により危険です。1つのオリジンから提供されるアプリケーションでユーザー資格情報を収集し、それを別のオリジンに送信すると、一定のセキュリティ上の脆弱性が生じる可能性があります。フィッシング攻撃の可能性が高くなり、バケツリレー攻撃も受けやすくなります。ユニバーサルログインにはオリジン間の情報交換がないため、クロスオリジンに関する懸念が解消されます。詳細については、「一般的なサイバーセキュリティの脅威を防止する」をお読みください。
- 埋め込みのユーザーエージェントはサードパーティにとって危険性が高く、これは認可サーバー自体にも当てはまります。埋め込みログインが使用されると、アプリは認可付与とユーザーの認証資格情報の両方を利用します。その結果、このデータが記録や悪意のある使用に対して脆弱なままになります。信頼できるアプリであっても、認可付与やユーザーの資格情報に対してアクセスを許可することは不必要です。これは、最小特権の原則（PoLP）に反し、攻撃の可能性を高める行為です。
Auth0を使ったユニバーサルログイン
ほとんどの場合では、Auth0が認証要求でログインページを表示するという、ユニバーサルログイン方策の使用が推奨されます。ログインページはDashboardを使ってカスタマイズできます。 Auth0のカスタムドメインを使用すると、ログインページとアプリ全体に同じドメインを維持することができます。ドメインが変わらないため、ユーザーが意識することなく、ログインページにリダイレクトできます。詳細については、「カスタムドメイン」をお読みください。 アプリが認証要求をトリガーすると必ず、ユーザーは認証のためにログインページにリダイレクトされます。この際に、Cookieが作成されます。その後の認証要求では、Auth0はこのCookieを確認します。このCookieがある場合には、ユーザーはログインページにリダイレクトされません。実際にログインが必要になときに限り、ログインページがユーザーに表示されます。を実装するには、これが最も手軽な方法です。 受信する認証要求が外部のIDプロバイダー（Facebookなど）を使用する場合には、ログインページが表示されないことに注意してください。その代わりに、Auth0はユーザーをIDプロバイダーのログインページへ送ります。 カスタムログインページは、GitHub、Bitbucket、GitLab、Microsoft Azureなどの外部リポジトリから導入することができます。 Auth0を使用する場合には、ユニバーサルログインの使用をお勧めします。まず第一に重要なのは、セキュリティです。埋め込みログインではなく、Auth0のユニバーサルログインをアプリケーションに使用することは、シームレスなクロスサイトリクエストフォージェリ（CSRF）対策になります。サードパーティのなりすましやセッションの乗っ取りから保護するのに役立ちます。Auth0を使った埋め込みログイン
Auth0を使ったWebアプリでの埋め込みログインには、クロスオリジン認証が使用されます（詳細については、「クロスオリジン認証」をお読みください）。サードパーティCookieを使用すると、異なるオリジン間で認証トランザクションを安全に行うことができます。これはネイティブアプリには該当しません。ネイティブアプリは標準のOAuth 2.0/tokenエンドポイントを利用します。サードパーティのクッキーについては、「追跡とプライバシー：サードパーティークッキー」（https://developer.mozilla.org）をお読みください。
Auth0はクロスオリジン認証を推奨しませんが、使用するのであれば、IDとパスワードを使用してディレクトリに対する認証を行う場合だけにしてください。ソーシャルやエンタープライズフェデレーションは異なるメカニズムを使用しており、OpenIDConnect（OIDC）やなどの標準プロトコルを介してリダイレクトします。さらに、クロスオリジン認証は、Web上の埋め込み型ログイン（Lockまたはauth0.jsを使用）にのみ適用されます。埋め込み型ログインを使用するネイティブアプリケーションは、標準のOAuth 2.0トークンエンドポイントを利用します。
また、カスタムドメインを有効にしている場合、エンドユーザーはサードパーティのCookieに対応しているブラウザーを使用しなければなりません。そうしないと、一部のブラウザーではクロスオリジン認証が失敗します。この制限は、従来型のID/パスワードのデータベース接続とパスワードレスのデータベース接続の両方に適用されます。