> ## 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.
> SPA を使用して、ユーザーが自分の別のアカウントで認証し、それらをプライマリアカウントにリンクできるクライアントサイド UI を提供する方法を説明します。
# ユーザー主導のアカウントリンク: クライアントサイド実装
Auth0 は、さまざまな アイデンティティプロバイダー 間でのユーザーアカウントのリンクをサポートしています。この機能を実装する方法の 1 つは、ユーザー自身が明示的にアカウントをリンクできるようにすることです。このシナリオでは、ユーザーは Single Page Application (SPA) の UI で認証し、後からリンクまたはボタンを使って別のアカウントを最初のアカウントにリンクできます。ユーザーがこのリンクまたはボタンをクリックすると、アプリケーションが呼び出しを行い、ユーザーが 2 つ目のプロバイダーでログインした際に、その 2 つ目のアカウントが 1 つ目のアカウントにリンクされます。
アカウントリンクを開始する際には、どのアイデンティティをプライマリアカウントとして使用し、どれをセカンダリアカウントとして使用するかを選択できます。この選択は、プライマリプロファイルに残したい属性セットによって決まります。保持されるのは、プライマリアカウントの属性のみだからです。
GitHub のこのプロジェクト [on GitHub](https://github.com/auth0-samples/auth0-link-accounts-sample/tree/master/SPA) を使って、React のサンプル Single Page Application を作成します。
このプロジェクトで、`auth_config.json` ファイルをテキストエディターで開き、domain と `client_id` をご利用の環境に合わせて更新します。
「Allowed Callback URLs」、「Allowed Logout URLs」、「Allowed Web Origins」フィールドに `http://localhost:3000` を追加します。
1. ユーザーをアプリケーションにログインさせます。
ユーザーは [Universal Login](/docs/ja-jp/authenticate/login/auth0-universal-login) を使用して SPA で認証を行い、[Management API 用のアクセストークン](https://auth0.com/docs/api/management/v2/get-access-tokens-for-spas) をリクエストします。
一般的な SPA のログインでは、コールバックは同じページ上でクライアント側で処理され、認証に成功すると JWT を受け取ります。詳しくは、[Single-Page App Quickstart](/docs/ja-jp/quickstart/spa) をご覧ください。
2. ユーザーがアカウントリンクを開始します。ユーザーが自分の別のアカウントとのリンクを開始できる UI を SPA で提供する必要があります。たとえば、SPA にユーザーの設定ページを用意できます。
ユーザーが **Link Account** ボタンをクリックすると、アプリケーションはユーザーを Universal Login ページにリダイレクトし、そこでリンクしたい接続を使ってログインさせます。認証が成功したら、取得したトークンを使ってアカウントをリンクします。
また、接続ごとにボタン (例: 'Link Facebook Account'、'Link Google Account') を追加し、`connection` パラメータを設定して (例: `/authorize?connection=facebook`) 、ユーザーを `/authorize` にリダイレクトすることもできます。
3. Auth0 Management API の [Link a User Account endpoint](https://auth0.com/docs/api/v2#!/Users/post_identities) を呼び出して、アカウントをリンクします。
セカンダリアカウントの `user_metadata` を保持してマージするには、API エンドポイントを呼び出す前にそのデータを取得し、プライマリアカウントのメタデータにマージしておく必要があります。アカウントがリンクされた後は、セカンダリアカウントのメタデータは破棄されます。
アカウントリンクを開始する際には、どの ID をプライマリアカウントとして使い、どの ID をセカンダリアカウントにするかを選択できます。この選択は、どの属性セットをプライマリプロファイルに残したいかによって決まります。
4. `linkAccount` 関数内で Management API を呼び出します。API にはプライマリ JWT (アクセストークン) を使って認証し、プライマリユーザーの ID とセカンダリ JWT (セカンダリユーザーの ID トークン) を使ってリンクします。
```javascript lines expandable theme={null}
const linkAccount = async () => {
const accessToken = await auth0.getTokenSilently();
const { sub } = await auth0.getUser();
// authenticateUser は、リンクする対象のアカウントでユーザーを認証する必要があります
// 詳細は Github のサンプルを参照してください
const {
__raw: targetUserIdToken,
email_verified,
email,
} = await authenticateUser();
if (!email_verified) {
throw new Error(
`Account linking is only allowed to a verified account. Please verify your email ${email}.`
);
}
await fetch(`https://${config.domain}/api/v2/users/${sub}/identities`, {
method: "POST",
headers: {
"Content-Type": "application/json",
Authorization: `Bearer ${accessToken}`,
},
body: JSON.stringify({
link_with: targetUserIdToken,
}),
});
};
```
以前は、場合によっては ID トークンを使ってユーザーアカウントのリンクおよびリンク解除を行うことができました。この機能は現在非推奨となっています。今後は、すべてのケースでアクセストークンを使用する必要があります。アカウントのリンク解除における変更点は、Authorization ヘッダーで ID トークンを使用できなくなったことです。代わりにアクセストークンを使用する必要があります。この機能自体は引き続き利用できますが、推奨はされておらず、該当するユーザーには移行が推奨されます。詳しくは、[Migration Guide: Account Linking with Access Tokens vs. ID Tokens](/docs/ja-jp/troubleshoot/product-lifecycle/past-migrations/link-user-accounts-with-access-tokens-migration) をご覧ください。
## 詳しく見る
* [ユーザーアカウントをリンクする](/docs/ja-jp/manage-users/user-accounts/user-account-linking/link-user-accounts)
* [ユーザーアカウントのリンク解除](/docs/ja-jp/manage-users/user-accounts/user-account-linking/unlink-user-accounts)
* [ユーザーアカウントのリンク: サーバーサイド実装](/docs/ja-jp/manage-users/user-accounts/user-account-linking/suggested-account-linking-server-side-implementation)