この廃止は潜在的なセキュリティ脆弱性に対応して行われます。できる限り早急にコードを更新することを強くお勧めします。
影響のある機能
アカウントリンクにおける変更点は以下のとおりです：-
AuthorizationヘッダーでIDトークンを使用できなくなりました。代わりにアクセストークンを使用する必要があります。 -
Authorizationヘッダーでアクセストークンを使用し、付与されたアクセス許可がupdate:usersの場合、要求のボディにはセカンダリアカウントのuser_idまたはIDトークンのいずれかを送信できます。 -
Authorizationヘッダーでアクセストークンを使用し、付与されたアクセス許可がupdate:current_user_metadataの場合、要求のボディにはセカンダリアカウントのIDトークンのみ送信できます。 -
要求の本文でセカンダリアカウントのIDトークンを送信する場合（上記2つのポイントで紹介したユースケース）、以下のような条件があります。
- IDトークンは
RS256を使用して署名される必要があります（この値は、［Dashboard］>［Clients（クライアント）］>［Client Settings（クライアントの設定）］>［Advanced Settings（高度な設定）］>［OAuth］ から設定できます。 - IDトークンの
audクレームは、クライアントを特定し、アクセストークンのazpクレームと同じ値でなければいけません。
- IDトークンは
-
Authorizationヘッダーでアカウントのリンクを解除する目的です。代わりにアクセストークンを使用しなければなりません。
| ユースケース | ステータス |
|---|---|
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.Managementのインスタンスを作成するために、auth0.jsライブラリーとプライマリアカウントのIDトークンを使用する。 | 影響あり |
auth0.Managementのインスタンスを作成するために、auth0.jsライブラリーと（update:usersスコープ付きの）アクセストークンを使用する。 | 影響なし |
auth0.Managementのインスタンスを作成するために、auth0.jsライブラリーと（update:current_user_identitiesスコープ付きの）アクセストークンを使用する。 | 影響あり |
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ヘッダーで送信する。 | 影響なし |
アクション
IDエンドポイントにリンクするアカウントへのすべての呼び出しを確認し、上記の脆弱なフローを利用する呼び出しを更新します。呼び出しを更新する方法には、次のようなものがあります。- クライアント側/ユーザー開始のリンクシナリオ: クライアント側のリンク シナリオの場合、
update:current_user_identitiesスコープのアクセス トークンを使用してIdentitiesエンドポイントへの呼び出しを行い、ペイロード（link_with）でセカンダリ アカウントの ID トークンを提供します。IDトークンは、/OIDC準拠のフローを通じて取得しなければなりません。 - サーバー側リンクシナリオ :サーバー側リンクシナリオの場合は、
update:usersスコープのアクセス トークンを使用してIdentitiesエンドポイントへの呼び出しを行い、ペイロードでセカンダリ アカウントのuser_idを指定します。
ユーザーアカウントをリンクする
ユーザーアカウントをリンクするには、のユーザーアカウントのリンクエンドポイントを呼び出すか、Auth0.jsライブラリを使用します。Management APIで現在のユーザーアカウントをリンクする
一般的なユースケースは、ログインしたユーザーに、アプリを使ってのアカウントのリンクを許可する、というものです。 非推奨になる前は、プライマリユーザーのIDトークンまたはアクセストークン（update:current_user_identitiesスコープを含む) を使用してManagement APIで認証し、ユーザーアカウントのリンクエンドポイントを使用できました。
次に、アクセストークン（update:current_user_identitiesスコープを含む）を取得し、それを使用してAPIで認証し、ユーザーアカウントのリンクエンドポイントを使用する必要があります。ペイロードは、セカンダリユーザーのIDトークンでなければなりません。
-
次の例に示すように、
update:current_user_identitiesスコープでアクセストークンを取得します。この例では暗黙的フローを使用していますが、任意の種類のアプリケーションのアクセストークンを取得できます。 -
以前の、IDトークンを使う方法では、コードは次のようになります：
アクセストークンを使う新しい方法だと、コードは次のようになります：
-
Management APIにアクセスできるアクセストークンを取得するには以下を行います。
-
audienceをhttps://{yourDomain}/api/v2/に設定する -
スコープ``${scope}を要求する -
response_typeをid_token tokenに設定し、Auth0がIDトークンとアクセストークンの両方を送るようにするアクセストークンをデコードすると、次のような内容になります：audはテナントのAPI URI、スコープは${scope}、subはログインユーザーのユーザーIDに設定されています。
-
-
次のような条件があります。
- セカンダリアカウントのIDトークンは
RS256で署名されている必要があります。 - セカンダリアカウントのIDトークンの
audクレームはクライアントを識別し、要求の作成に使用されたアクセス トークンのazpクレームと同じ値を保持する必要があります。
- セカンダリアカウントのIDトークンは
-
アクセストークンを取得したら、それを使ってユーザーアカウントをリンクします。この部分は同じで、要求のうち、
Bearerトークンとして使用する値を除き変更はありません。応答も同じです。
auth0.jsを使って現在のユーザーアカウントをリンクする
auth0.jsライブラリを使用してManagement APIにアクセスし、アカウントをリンクする場合は、おそらくユーザーのプライマリ ID の ID トークンを使用してauth0.Managementをインスタンス化し、それを使用してアカウントをリンクします。
-
update:current_user_identitiesスコープのアクセス トークンを取得し、このトークンを使用してauth0.Managementをインスタンス化します。linkUserへの最後の呼び出しは変わりません。 -
以前の、IDトークンを使う方法では、コードは次のようになります：
アクセストークンを使う新しい方法だと、コードは次のようになります：
- 応答でIDトークンとアクセストークンの両方を求めます（
responseType:token id_token“）。 - Management APIを意図したトークンのオーディエンスとして設定します（
audience:https:///api/v2/“）。 - 必要な許可を要求します（
scope:update:current_user_identities“）。 - アクセストークンを使ってManagement APIで認証します。
- 応答でIDトークンとアクセストークンの両方を求めます（
Management APIで任意のユーザーアカウントをリンクする
update:usersスコープを含むアカウント リンク用のアクセス トークンを取得し、要求でセカンダリーアカウントの user_idとプロバイダーを送信する場合は、何も変更する必要はありません。
ただ、ここで紹介している新しいメソッドはその代わりになります。APIでの認証には引き続きupdate:usersスコープを含むアクセストークンを使用しますが、要求のペイロードでセカンダリのアカウントIDトークンを（user_idおよびプロバイダーの代わりに）送信できます。
- セカンダリアカウントのIDトークンは
RS256で署名されている必要があります。 - セカンダリアカウントのIDトークンの
audクレームはクライアントを識別し、要求の作成に使用されたアクセス トークンのazpクレームと同じ値を保持する必要があります。
ユーザーアカウントのリンクを解除する
IDトークンを使ってアカウントのリンクを解除するには、アクセストークンを使うようコードを更新しなければなりません。-
まず、
update:current_user_identitiesスコープのアクセストークンを取得する必要があります。 -
以前の、IDトークンを使う方法では、コードは次のようになります：
アクセストークンを使う新しい方法だと、コードは次のようになります：
-
Management APIにアクセスできるアクセストークンを取得するには以下を行います。
-
audienceをhttps://{yourDomain}/api/v2/に設定する -
スコープ``${scope}を要求する -
response_typeをid_token tokenに設定し、Auth0がIDトークンとアクセストークンの両方を送るようにするアクセストークンをデコードすると、次のような内容になります：audはテナントのAPI URI、スコープはupdate:current_user_identities、subはログインユーザーのユーザーIDに設定されています。
-
-
アクセストークンを取得したら、
Authorizationヘッダーでそれを使用して、Management API のユーザーIDエンドポイントのリンク解除を呼び出すことができます。 -
以前の方法では、呼び出しは次のようになります：
新しい方法では、呼び出しは次のようになります：
セキュリティに関する考慮事項
ある特定のアカウントリンクフローに、特殊な状況において悪用される可能性のある弱点が見つかりました。実際に悪用された証拠はありませんが、予防策としてこのフローを廃止することが決まりましたので、 当該のアカウントリンクフローを使用している方は、2018年10月19日までに安全な実装へと移行するようお願いしています。このガイドでご紹介している移行パスをご利用いただけば、どの機能も失われません。 2018年10月19日以降、当該のアカウントリンクフローは無効になり、ランタイムエラーが生じます。 Authorizationヘッダーにスコープupdate:current_user_identitiesを含むトークン（IDまたはアクセストークン）を使用してPost Identitiesエンドポイントを呼び出し、ペイロードにセカンダリアカウントのuser_idを含めると、影響を受けます。その他のユースケースは影響を受けません。