メインコンテンツへスキップ
を使用してエンドポイントを呼び出す方法は、非推奨となります。代わりに を使用する必要があります。この移行の猶予期間は 2018 年 3 月 31 日 に開始されました。 アクセストークンへの移行が完了したら、Dashboard で Allow ID Tokens for Management API v2 Authentication トグルをオフにしてください。 次のいずれかのエンドポイントの呼び出しに IDトークンを使用している場合、この移行の対象となります。これらのエンドポイントでは、通常のアクセストークンを使用できるようになりました。エンドポイントの動作にそれ以外の変更はありません。リクエストおよびレスポンスのスキーマは変わらないため、認可に使用するトークンを更新するだけで済みます。

​
影響を受けるエンドポイント

エンドポイントユースケース
GET /api/v2/users/ユーザー情報を取得する
GET /api/v2/users//enrollmentsユーザーの Guardian MFA 登録をすべて取得する
PATCH /api/v2/users/ユーザー情報を更新する
DELETE /api/v2/users//multifactor/ユーザーの MFA プロバイダー設定を削除する
POST /api/v2/device-credentialsデバイスの公開鍵を作成する
DELETE /api/v2/device-credentials/デバイス認証情報を削除する
POST/api/v2/users//identities各種 IDプロバイダーのユーザーアカウントをリンクする
DELETE /api/v2/users//identities//ユーザーアカウントのリンクを解除する

​
Actions

​
スコープの変更

Management API で実行できる操作は、アクセストークンに含まれるスコープによって異なります。この移行により、ログイン中のユーザーのデータのみを更新できる制限付きアクセストークン、または任意のユーザーのデータを更新できるアクセストークンを取得できます。次のマトリクスでは、ケース別およびエンドポイント別に、トークンに必要なスコープを確認できます。 たとえば、トークンにスコープ read:users が含まれている場合は、GET /api/v2/users/{id} エンドポイントを使用して任意のユーザーのデータを取得できます。一方、トークンにスコープ read:current_user が含まれている場合は、現在ログインしているユーザー (そのトークンの発行対象であるユーザー) の情報のみを取得できます。
エンドポイント現在のユーザー用のスコープ任意のユーザー用のスコープ
GET /api/v2/users/read:current_userread:users
GET /api/v2/users//enrollmentsread:current_userread:users
POST/api/v2/users//identitiesupdate:current_user_identitiesupdate:users
DELETE /api/v2/users//identities//update:current_user_identitiesupdate:users
PATCH /api/v2/users/update:current_user_metadataupdate:users
PATCH /api/v2/users/create:current_user_metadataupdate:users
DELETE /api/v2/users//multifactor/delete:current_user_metadataupdate:users
POST /api/v2/device-credentialscreate:current_user_device_credentialscreate:device_credentials
DELETE /api/v2/device-credentials/delete:current_user_device_credentialsdelete:device_credentials

​
アクセストークンを取得する

Auth0 では、前述のエンドポイントのトークン取得方法が変更されました。ユーザーを認証してトークンを取得する方法は、使用する技術と、認証に使用する フローに応じていくつかあります。
  • ブラウザーで実行される SPA: 認可エンドポイントを使用します。
  • サーバー上で実行される Web アプリ、モバイルアプリ、サーバープロセス、または信頼性の高いアプリ: を使用します。
  • クロス認証: リクエストが異なるドメインから送信される場合は、埋め込み型の Lock または auth0.js を使用してユーザーを認証します。

​
認可エンドポイント

このセクションでは、認可エンドポイントでトークンを取得する方法の違いを、例を使って説明します。どのエンドポイントを移行する場合でも、必要な変更は同じであり、異なるのはリクエストで指定するスコープだけであることに注意してください。 以下の例では、ログイン中のユーザーの完全なユーザープロファイル情報を取得するために、GET User by ID エンドポイントを使用します。そのため、まず Implicit グラントを使用してユーザーを認証し、トークンを取得します。以下は、IDトークンを取得してからそれを使ってエンドポイントを呼び出す、従来の方法の実装例です。 以下の例では、アクセストークンを取得する新しいアプローチを確認できます。 Management API にアクセスできるアクセストークンを取得するには、次のように設定します。
  • audience を https://{yourDomain}/api/v2/ に設定します
  • スコープ ${scope} を要求します
  • Auth0 が IDトークン とアクセストークンの両方を送信するように、response_type を id_token token に設定します
受け取ったアクセストークンをデコードして内容を確認すると、次のようになります。 aud にはテナントの API URI、scope には ${scope}、sub にはログイン中のユーザーのユーザー ID が設定されていることに注意してください。 アクセストークンを取得したら、それを使ってエンドポイントを呼び出せます。この部分は変わらず、リクエストで変わるのは Bearer トークンとして使用する値だけです。レスポンスも変わりません。

​
トークンエンドポイント

このセクションでは、トークンエンドポイントを使ってトークンを取得する方法の違いを、例を用いて説明します。ただし、どのエンドポイントを移行する場合でも変更内容は同じで、異なるのはリクエストで指定するスコープだけです。 以下の例では、ログイン中のユーザーの完全なユーザープロファイル情報を取得するために、GET User by ID エンドポイントを使用します。まず、Password Exchange grant を使用してユーザーを認証し、その後トークンを取得します。以下は、IDトークンを取得し (その後それを使ってエンドポイントを呼び出す) 、従来の方法を実装した例です。 以下の例では、アクセストークンも取得できる新しい方法を確認できます。 Management API にアクセスできるアクセストークンを取得するには、次のようにします。
  • aud を https://{yourDomain}/api/v2/ に設定します
  • read:current_user スコープを要求します
アクセストークンを取得したら、それを使ってエンドポイントを呼び出せます。この部分は同じで、リクエストで変わるのは Bearer トークンとして使用する値だけです。レスポンスも同じです。

​
埋め込み型 Lock または auth0.js

アプリケーションに Lock または auth0.js v9 を埋め込んでいる場合は、クロスオリジン認証を使用しています。これは、異なるドメインから送信されるリクエストでユーザーを認証するために使用されます。 auth0.js を使用して Management API にアクセスし、ユーザーを管理している場合は、スクリプトを更新する必要があります。 以下の例は、従来の方法を示しています。 この例では、新しい方法を確認できます。
  • レスポンスで IDトークン とアクセストークンの両方を要求します responseType: 'token id_token'
  • トークンのとして Management API を設定します audience: 'https://YOUR_DOMAIN/api/v2/'
  • 必要な権限を要求します scope: 'read:current_user'
  • アクセストークンを使用して Management API に対して認証します

​
Account Linking の変更

この機能の変更点は次のとおりです。
  • Authorization ヘッダーでは IDトークンを使用できなくなりました
  • Authorization ヘッダーで、update:users 権限が付与されたアクセストークンを使用する場合は、リクエスト本文でセカンダリアカウントの user_id または IDトークンのいずれかを送信できます
  • Authorization ヘッダーで、update:current_user_metadata 権限が付与されたアクセストークンを使用する場合は、リクエスト本文でセカンダリアカウントの IDトークンのみを送信できます。次の条件を満たしている必要があります。
    • IDトークンは RS256 で署名されている必要があります (この値は Dashboard > Applications > Application Settings > Advanced Settings > OAuth で設定できます)
    • IDトークンのクレーム aud はアプリケーションを識別している必要があり、アクセストークンの azp クレームと同じ値である必要があります

​
制限事項

Management API へのアクセスに使用するアクセストークンでは、aud クレームに設定できる値は 1 つのみです。トークンに複数の値が含まれている場合、Management API へのリクエストはエラーになります。

​
詳細情報