Skip to main content
API に対して発行された は、その対象となる API のみが検証する必要があります。
IDプロバイダー (IdP) のアクセストークンは検証する必要がありません。IdP アクセストークンを発行元の IdP に渡して検証を行ってください。詳しくは、Identity Provider Access Tokensを参照してください。
これらのチェックのいずれかに失敗した場合、そのトークンは無効と見なされ、リクエストは 401 Unauthorized を返して拒否しなければなりません。
  1. 標準的な JWT 検証を実行します。 アクセストークンは JWT であるため、標準的な JWT の検証手順を実行する必要があります。詳しくは Validate JSON Web Tokens を参照してください。
  2. トークンの audience クレームを検証します。 標準的な JWT 検証を実行していれば、JWT のペイロードはすでにデコードされており、その標準クレームも確認済みのはずです。トークンの audience クレーム (aud、文字列の配列) は、最初のトークンリクエストによって決まります。aud フィールドには、カスタム API に対応する audience と、/userinfo エンドポイントに対応する audience の両方が含まれる場合があります。トークンの audience 値のうち少なくとも 1 つは、API’s Settings の Identifier フィールドで定義されている対象 API の一意の識別子と一致している必要があります。詳しくは アクセストークンを取得する を参照してください。
  3. 権限 (スコープ) を検証します。 アプリケーションに、API へアクセスするために必要な権限が付与されていることを確認します。そのためには、デコードされた JWT のペイロードにある scope クレーム (scope、スペース区切りの文字列リスト) を確認する必要があります。これは、アクセス対象のエンドポイントに必要な権限と一致している必要があります。たとえば、カスタム API がユーザーレコードの読み取り、作成、削除を行う 3 つのエンドポイントを提供している場合、API を Auth0 に登録した際に、それに対応する 3 つの権限を作成します。
    1. create:users は /create エンドポイントへのアクセスを提供します
    2. read:users は /read エンドポイントへのアクセスを提供します
    3. delete:users は /delete エンドポイントへのアクセスを提供します
    この場合、アプリケーションが /create エンドポイントへのアクセスをリクエストしても、アクセストークンの scope クレームに create:users という値が含まれていなければ、API はそのリクエストを拒否する必要があります。

​
詳しくはこちら