利用可否はAuth0のプランによって異なります
この機能を利用できるかどうかは、ログイン実装の内容に加え、Auth0のプランや個別契約によって異なります。詳しくは、Pricingをご覧ください。
- 外部リンク用アプリケーションを使用するAction
- Auth0
- auth0.js ライブラリ
外部リンク用アプリケーションを使用する Action
Action を外部リンク用アプリケーションと組み合わせることで、Management API を使用してユーザーアカウントをリンクできます。 以下の手順は、実装例を示しています。- Action が、リンク候補となるユーザーアカウントを特定します (存在する場合) 。
-
Action は、候補となるユーザーアイデンティティを含むトークンペイロードとともに、ユーザーを外部リンク用アプリケーションにリダイレクトします。
- 外部リンク用アプリケーションは、ユーザーがリンクしたいアカウントの認証情報を使って認証するよう求めます。
-
外部リンク用アプリケーションは、プライマリおよびセカンダリのユーザーアイデンティティを含むトークンペイロードとともに、ユーザーを Action にリダイレクトします。
- Action がトークンの真正性と内容を検証します。
- Action は、外部リンク用アプリケーションから返された結果に基づいて Management API を呼び出し、アカウントをリンクします。
-
event.user.user_idと一致しない場合、Action はプライマリユーザーに切り替えます。
外部リンク用アプリケーションの実行中、元のログイン取引は一時停止され、ユーザーの現在の Auth0 セッションに紐付けられた状態になります。アプリケーションが元のログインと同じ Auth0 ドメインで
/authorize を呼び出して2つ目のアカウントを認証すると、この2回目のログインによってセッションが置き換えられてしまいます。その結果、/continue の呼び出しが Unable to process redirect callback エラーで失敗します。このエラーは、無効な state パラメーターを指定して /continue を呼び出した場合によく発生します。これを回避するには、ログインが完了し、一時停止中の取引がない状態でアカウントをリンクしてください。詳細については、通常の Web アプリの場合はユーザーアカウントのリンク:サーバー側の実装を、シングルページアプリの場合はユーザー主導のアカウントリンク:クライアント側の実装をお読みください。例: アカウントリンク Action
Management API
Management API の ユーザーアカウントをリンクする エンドポイントは、次の 2 つの方法で使用できます。update:current_user_identitiesスコープを持つ を使った、ユーザー主導のクライアントサイドでのアカウントリンク。update:usersスコープを持つアクセストークンを使った、サーバーサイドでのアカウントリンク。
ユーザー主導のクライアントサイドでのアカウントリンク
ユーザー主導のクライアントサイドでのアカウントリンクでは、ペイロードに次の項目を含むアクセストークンが必要です。update:current_user_identitesスコープ- URL の一部として指定する、プライマリアカウントの
user_id - RS256 で署名され、リクエスト元のアクセストークンの
azpクレームの値と一致するクライアントを識別するaudクレームを含む、セカンダリアカウントの
update:current_user_identities スコープを含むアクセストークンは、現在ログインしているユーザーの情報を更新する場合にのみ使用できます。したがって、この方法は、ユーザー自身がリンク処理を開始するシナリオに適しています。
Auth0 CLI を使用していますか?まだセットアップしていない場合は、このコマンドを実行する前に CLI セッションをセットアップして認証してください。
サーバーサイドでのアカウントリンク
サーバーサイドでアカウントをリンクするには、ペイロードに次の項目を含むアクセストークンが必要です。update:usersスコープ- URL の一部として指定するプライマリアカウントの
user_id - セカンダリアカウントの
user_id - RS256 で署名され、リクエスト元のアクセストークンの
azpクレームの値と一致するクライアントを識別するaudクレームを含む、セカンダリアカウントの ID トークン
update:users スコープを含むアクセストークンは、任意のユーザーの情報を更新するために使用できます。そのため、この方法はサーバーサイドのコードでのみ使用することを想定しています。
セカンダリユーザーアカウントの user_id と provider は、その一意の識別子から判別できます。たとえば、識別子が google-oauth2|108091299999329986433 の場合:
providerはgoogle-oauth2user_idは108091299999329986433
provider と user_id の代わりに、セカンダリアカウントの ID トークンを送信することもできます: