以前は、一部のユースケースでユーザーアカウントのリンクおよびリンク解除に IDトークン を使用できました。Auth0 はこの機能を非推奨とします。今後は、すべてのケースで アクセストークン を使用する必要があります。
この非推奨化は、潜在的なセキュリティ脆弱性に対応するためのものです。Auth0 は、できるだけ早くコードを更新することを強く推奨します。
アカウントリンクの変更点は次のとおりです。
Authorization ヘッダーでは IDトークンを使用できなくなりました。代わりにアクセストークンを使用する必要があります。
付与された権限が update:users のアクセストークンを Authorization ヘッダーで使用する場合、リクエスト本文にはセカンダリアカウントの user_id または IDトークンのいずれかを送信できます。
付与された権限が update:current_user_metadata のアクセストークンを Authorization ヘッダーで使用する場合、リクエスト本文にはセカンダリアカウントの IDトークンのみを送信できます。
リクエスト本文でセカンダリアカウントの IDトークンを送信する場合 (前の 2 つの箇条書きで説明したユースケース) 、次の条件を満たす必要があります。
IDトークンは RS256 で署名されている必要があります (この値は Dashboard > Clients > Client Settings > Advanced Settings > OAuth で設定できます) 。
IDトークンの aud クレームはクライアントを識別し、アクセストークンの azp クレームと同じ値である必要があります。
アカウントのリンク解除では、Authorization ヘッダーで IDトークンを使用できなくなりました。代わりにアクセストークンを使用する必要があります。
アカウントをリンクおよびリンク解除する方法はいくつかあります。以下の一覧では、各ユースケースと、それぞれがどのように影響を受けるかを確認できます。
Use Case Status Management API の POST /api/v2/users/{id}/identities エンドポイントを使用し、プライマリアカウントの IDトークンを Authorization ヘッダーで送信する。 影響あり Management API の POST /api/v2/users/{id}/identities エンドポイントを使用し、アクセストークン (スコープ update:users) を authorization ヘッダーで、セカンダリアカウントの user_id をペイロードで送信する。 影響なし Management API の POST /api/v2/users/{id}/identities エンドポイントを使用し、アクセストークン (スコープ update:current_user_identities) を Authorization ヘッダーで、セカンダリアカウントの user_id をペイロードで送信する。 影響あり Management API の POST /api/v2/users/{id}/identities エンドポイントを使用し、アクセストークンを Authorization ヘッダーで、セカンダリアカウントの IDトークンをペイロードで送信する。 新しいユースケース auth0.js ライブラリとプライマリアカウントの IDトークンを使用して auth0.Management をインスタンス化する。 影響あり auth0.js ライブラリとアクセストークン (スコープ update:users) を使用して auth0.Management をインスタンス化する。 影響なし auth0.js ライブラリとアクセストークン (スコープ update:current_user_identities) を使用して auth0.Management をインスタンス化する。 影響あり Management API の DELETE /api/v2/users/{id}/identities/{provider}/{user_id} エンドポイントを使用し、プライマリアカウントの IDトークンを Authorization ヘッダーで送信する。 影響あり Management API の DELETE /api/v2/users/{id}/identities/{provider}/{user_id} エンドポイントを使用し、アクセストークンを Authorization ヘッダーで送信する。 影響なし
アカウントリンクに関する Identities endpoint へのすべての呼び出しを確認し、上記の脆弱なフローを使用しているものを更新してください。呼び出しは、次のいずれかの方法に更新できます。
クライアント側 / ユーザー主導のリンクシナリオ: クライアント側のリンクシナリオでは、update:current_user_identities スコープを持つアクセストークンを使用して Identities endpoint を呼び出し、ペイロード (link_with) にセカンダリアカウントのIDトークンを指定します。このIDトークンは、OAuth /OIDC準拠フローを通じて取得する必要があります。
サーバー側のリンクシナリオ : サーバー側のリンクシナリオでは、update:users スコープを持つアクセストークンを使用して Identities endpoint を呼び出し、ペイロードにセカンダリアカウントの user_id を指定します。
詳しくは、Link User Accounts を参照してください。
ユーザーアカウントをリンクするには、Management API の Link a User Account エンドポイント を呼び出すか、Auth0.js ライブラリ を使用します。
Management API を使用して現在ログインしているユーザーのアカウントをリンクする
一般的なユースケースとして、ログイン中のユーザーがアプリを使って自分のアカウントをリンクできるようにすることがあります。
非推奨になる前は、プライマリユーザーの IDトークン または アクセストークン (update:current_user_identities スコープを含む) を使用して Management API に対して認証し、Link a User Account endpoint を利用できました。
現在は、アクセストークン (update:current_user_identities スコープを含む) を取得し、それを使用して API に対して認証し、Link a User Account endpoint を利用する必要があります。ペイロードにはセカンダリユーザーの IDトークン を指定する必要があります。
次の例に示すように、update:current_user_identities スコープを含むアクセストークンを取得します。この例では implicit flow を使用していますが、どのアプリケーションタイプでも アクセストークンを取得 できます。
以前の IDトークン を使用する方法では、コードは次のようになります。
新しいアクセストークンを使用する方法では、コードは次のようになります。
Management API にアクセスできるアクセストークンを取得するには、次のようにします。
audience を https://{yourDomain}/api/v2/ に設定します。
scope として ${scope} を要求します。
response_type を id_token token に設定して、Auth0 が IDトークン と アクセストークン の両方を返すようにします。
アクセストークンをデコードして内容を確認すると、次のようになっていることがわかります。
aud にはテナントの API URI、scope には ${scope}、sub にはログイン中のユーザーのユーザー ID が設定されていることに注目してください。
次の条件を満たす必要があります。
セカンダリアカウントの IDトークン は RS256 で署名されている必要があります。
セカンダリアカウントの IDトークン 内の aud クレームはクライアントを識別し、リクエストに使用するアクセストークンの azp クレームと同じ値である必要があります。
アクセストークンを取得したら、それを使用してユーザーアカウントをリンクできます。この部分は変わらず、リクエストで変更されるのは Bearer トークンとして使用する値だけです。レスポンスも同じです。
auth0.js で現在のユーザーアカウントをリンクする
auth0.js library を使用して Management API にアクセスし、アカウントをリンクする場合は、通常、ユーザーのプライマリアイデンティティの IDトークンを使って auth0.Management をインスタンス化し、それを使ってアカウントをリンクします。
update:current_user_identities スコープを持つアクセストークンを取得し、そのトークンを使用して auth0.Management をインスタンス化します。最後の linkUser の呼び出しはそのまま同じです。
以前の IDトークンを使用する方法では、コードは次のようになります。
新しいアクセストークンを使用する方法では、コードは次のようになります。
レスポンスとして IDトークンとアクセストークンの両方を要求します (responseType: `token id_token`)。
トークンのオーディエンスとして Management API を設定します (audience: `https://YOUR_DOMAIN/api/v2/`)。
必要な権限を要求します (scope: `update:current_user_identities`)。
アクセストークンを使用して Management API に対して認証します。
Management API を使用して任意のユーザーアカウントをリンクする
アカウントリンク用に update:users スコープを含むアクセストークンを取得し、リクエストでセカンダリアカウントの user_id と provider を送信する場合は、変更を加える必要はありません。
ただし、この新しい方法では別のやり方も利用できます。API の認証には引き続き update:users スコープを含むアクセストークンを使用しますが、リクエストのペイロードでは、user_id と provider の代わりにセカンダリアカウントの IDトークンを送信できます。
セカンダリアカウントのIDトークンは、RS256 で署名されている必要があります。
セカンダリアカウントのIDトークン内の aud クレームはクライアントを識別する必要があり、リクエストの実行に使用するアクセストークンの azp クレームと同じ値である必要があります。
アカウントのリンク解除に IDトークン を使用している場合は、アクセストークンを使用するようにコードを更新する必要があります。
まず、update:current_user_identities スコープを含むアクセストークンを取得する必要があります。
従来の IDトークン を使用する方法では、コードは次のようになります。
新しいアクセストークンを使用する方法では、コードは次のようになります。
Management API にアクセスできるアクセストークンを取得するには、次のようにします。
audience を https://{yourDomain}/api/v2/ に設定します。
scope として ${scope} を要求します。
response_type を id_token token に設定し、Auth0 が IDトークン とアクセストークンの両方を返すようにします。
アクセストークンをデコードして内容を確認すると、次のようになります。
aud はテナントの API URI、scope は update:current_user_identities、sub はログイン中のユーザーのユーザー ID に設定されていることがわかります。
アクセストークンを取得したら、それを Authorization ヘッダーで使用して、Management API の Unlink a user identity endpoint を呼び出すことができます。
従来の方法では、呼び出しは次のようになります。
DELETE https://YOUR_DOMAIN/api/v2/users/{primaryAccountUserId}/identities/{secondaryAccountProvider}/{secondaryAccountUserId}
Authorization: 'Bearer { yourIdTokenOrMgmtApiAccessToken }'
新しい方法では、呼び出しは次のようになります。
特定のアカウントリンクフローに、一定の条件下で不正利用される可能性のある脆弱性があることを確認しました。現時点では、この問題が悪用された証拠は確認されていませんが、そのような事態を確実に防ぐため、このフローを非推奨にすることを決定しました。
そのため、該当するアカウントリンクフローを使用している Auth0 のお客様は、2018 年 10 月 19 日までに、より安全な実装へ移行する必要があります。このガイドでは移行方法を案内しており、機能が失われることはありません。
2018 年 10 月 19 日以降、該当するアカウントリンクフローは無効化され、実行時エラーが発生します。
Authorization ヘッダーでスコープ update:current_user_identities を持つトークン (ID トークンまたはアクセストークン) を使用して Post Identities endpoint を呼び出し、ペイロードにセカンダリアカウントの user_id を含めている場合は、影響を受けます。これ以外のユースケースには影響ありません。