埋め込み型ログインからユニバーサルログインへの移行
Auth0をアプリケーションに統合するときは、埋め込み型ログインとユニバーサルログインのどちらを使用するかを決める必要があります。
埋め込み型ログインでは、ログインダイアログがアプリケーションによってホストされます。ロックを使用することも、独自のUIを作成してauth0.jsを使用することもできます。
ユニバーサルログインを使用すると、Auth0によってホストされるログインページにリダイレクトされます。そこで、認証フローが実行されます。
ユニバーサルログインには、埋め込み型ログインに比べていくつかの利点があります。詳細な分析については、「中央集中型ログインと埋め込み型ログイン」を参照してください。
また、クイックスタートを使用して、ユニバーサルログインを複数の技術スタックに実装する方法もご覧いただけます。
シングルサインオンを使った埋め込み型ログインのシナリオ
LockおよびAuth0.jsのレガシーバージョンからの移行が必要です。シングルサインオン（SSO）のシナリオでは、ほとんどの場合、ユニバーサルログインへの移行を意味します。
シングルページアプリ
埋め込み型ログインを使ったシングルページアプリケーション（SPA）は、同じトップレベルのドメイン上にある場合にのみSSOを実現できます。異なるドメイン上にあるログインが埋め込み型ログインを使ったSPAでSSOが必要な場合は、そのWebサイトをユニバーサルログインに移行する必要があります。
SSOは、特定のドメインのAuth0サーバー内のセッションを識別するCookieをAuth0に設定させることで機能します。
埋め込み型ログインを適切に機能させるためには、Webサイトのトップレベルのドメインと一致するカスタムドメインを設定して、クロスオリジン認証の問題を回避する必要があります。
埋め込み型ログインを使用する2つのアプリケーションが異なるトップレベルのドメインに存在する場合、埋め込み型ログインを適切に実装するには、それらのアプリケーションが2つの異なるカスタムドメインを指し示す必要があります。2つのアプリケーションが異なるドメイン上にある場合、それらのドメインは同じSSO Cookieを共有できないため、それらのサイト間でSSOを実装することはできません。
Webアプリ
SSOを必要とする埋め込み型ログインを使ったWebアプリケーションは、ユニバーサルログインに移行する必要があります。
Webアプリケーションに埋め込み型ログインを実装する適切な方法は、そのWebアプリケーションに資格情報をPOSTするカスタムフォームを作成することです。その後、Webアプリケーションは/oauth/tokenエンドポイントを使用して、Auth0で検証します。
Auth0サーバーはエンドユーザーのブラウザーにCookieを設定できないため、このアプローチではSSOセッションを作成できません。また、Auth0が攻撃防御を実行することもできません。