メインコンテンツへスキップ
は API 向けのものであり、検証を行うのはそのトークンの発行対象である API のみとすべきです。
Identity Provider (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 の一意識別子と一致している必要があります。詳細は Get Access Tokens を参照してください。
  3. 権限 (スコープ) を検証します。 アプリケーションに、API へのアクセスに必要な権限が付与されていることを確認します。そのためには、デコードした JWT のペイロードに含まれる scope クレーム (scope、スペース区切りの文字列リスト) を確認する必要があります。これは、アクセスしようとしているエンドポイントに必要な権限と一致している必要があります。たとえば、カスタム API がユーザーレコードの読み取り、作成、削除のための 3 つのエンドポイントを提供している場合、Auth0 に API を登録した際に、それぞれに対応する 3 つの権限を作成します。
    1. create:users は /create エンドポイントへのアクセス権を付与します
    2. read:users は /read エンドポイントへのアクセス権を付与します
    3. delete:users は /delete エンドポイントへのアクセス権を付与します
    この場合、アプリケーションが /create エンドポイントへのアクセスを要求していても、アクセストークンの scope クレームに create:users が含まれていなければ、API はそのリクエストを拒否すべきです。

​
さらに詳しく