メインコンテンツへスキップ

利用可否は Auth0 のプランによって異なります

この機能を利用できるかどうかは、Auth0 のプランまたはカスタム契約の内容によって異なります。詳細については、Pricing を参照してください。
Auth0 が返すほとんどの IDトークンと は、さまざまなクレームを含む (JWT) です。クレームとは、対象に関して表明される情報のことです。たとえば、IDトークン (これは常に JWT です) には、認証中のユーザーの名前が “John Doe” であることを示す name というクレームを含めることができます。 JWT クレームには 2 種類あります。
  • Registered: サードパーティまたは外部アプリケーションとの相互運用性を確保するために、JWT specification で定義されているクレームです。OpenID Connect (OIDC) の標準クレームは予約済みクレームです。
  • Custom: 独自に定義するクレームです。これらのクレームには、未登録で衝突耐性のあるパブリッククレームと、衝突する可能性がある未登録の非公開プライベートクレームがあります。予約済みクレームや他のカスタムクレームとの衝突を避けるため、namespacing などを使用して、これらのクレームには慎重に名前を付けてください。異なる情報を含む同名のクレームが 2 つあると、扱いが難しくなる場合があります。
クレームの詳細については、JSON Web Token Claims を参照してください。

​
組織経由でユーザーを認証する

組織経由でユーザーを認証するには、/authorize エンドポイントの呼び出しに organization パラメーターを追加します。ユーザーが組織経由でログインしたときに返されるトークンの例を以下に示します。
デフォルトでは、ID トークンとアクセストークンには組織 ID のみが含まれます。ただし、テナントを設定することで、Authentication API で組織名を使用できるようになります。設定後は、ID トークンとアクセストークンの両方に org_id と org_name のクレームが含まれます。詳細については、Authentication API で組織名を使用するを参照してください。

​
IDトークン

次の例では、https://marketplace/roles と https://namespace.exampleco.com/ はトークンに追加されたカスタムクレームであり、それ以外に含まれるクレームは標準クレームであることに注意してください。 
{
  "https://marketplace/roles": [
    "marketplace-administrator"
  ],
  "https://namespace.exampleco.com": "my custom claim",
  "nickname": "firstName.lastName",
  "name": "firstName.lastName@email.com",
  "picture": "https://s.gravatar.com/avatar/638",
  "updated_at": "2021-03-23T11:34:14.566z",
  "email": "username@exampleco.com",
  "email_verified": true,
  "sub": "auth0|602c0dcab993d10073daf680",
  "org_id": "org_9ybsU1dN2dKfDkBi"
}

​
アクセストークン

{
  "iss": "https://exampleco.auth0.com/",
  "sub": "auth0|602c0dcab993d10073daf680",
  "aud": [
    "https://example-api/",
    "https://exampleco.auth0.com/userinfo"  
  ],
  "iat": 1616499255,
  "exp": 1616585655,
  "azp": "ENDmmAJsbwI1hOG1KPJddQ8LHjV6kLkV",
  "scope": "openid profile email",
  "org_id": "org_9ybsU1dN2dKfDkBi",
  "permissions": [
    "delete:stuff",
    "read:stuff",
    "write:stuff"  
  ]
}

​
組織へのマシン間アクセス

マシン間のユースケースでは、アプリケーションがユーザーではなく自身のアクセストークンを取得できるよう、organization パラメーターが /oauth/token エンドポイントへの Client Credentials リクエストに追加されます。
デフォルトでは、ID トークンとアクセストークンには組織 ID のみが含まれます。ただし、Authentication API で組織名を使用できるようにテナントを設定することもできます。この設定を有効にすると、ID トークンとアクセストークンには org_id クレームと org_name クレームの両方が含まれます。詳しくは、Use Organization Names in the Authentication API を参照してください。
以下のコードサンプルは、マシン間のユースケースで返されるアクセストークンの例です。 
{
  "iss": "https://exampleco.auth0.com/",
  "sub": "CS2MNgcX1VZFCJaEzfKw2VPAAS0gzhqP@clients",
  "aud": "https://example-api",
  "iat": 1727782196,
  "exp": 1727868596,
  "scope": "scope1 scope2",
  "org_id": "org_vIK75NKFvaozQsFy",
  "org_name": "acme",
  "gty": "client-credentials",
  "azp": "CS2MNgcX1VZFCJaEzfKw2VPAAS0gzhqP"
}

​
トークンを検証する

organization パラメーターを /authorize エンドポイントまたは /oauth/token エンドポイントへの呼び出しに追加すると、Auth0 SDK は、生成されたトークンに含まれる org_id クレームを自動的に検証します。ただし、セキュリティ上の理由から、トークンを受信した際には追加の検証を行う必要があります。
テナントで Authentication API における組織名の使用を許可するよう設定している場合、IDトークンとアクセストークンには org_id クレームと org_name クレームの両方が含まれます。これらのクレームが存在する場合は、受信した値が信頼できるエンティティに対応していることを確認するため、org_id に加えて org_name クレームも検証してください。一般に、トークンの検証には組織 ID を使用する方法が推奨されます。ただし、ユースケースによっては組織名を使用するほうが適切な場合もあります。組織名を使ってトークンを検証することによる影響を理解するには、Authentication API で組織名を使用する を参照してください。
Web アプリケーションの場合: organization パラメーターが /authorize エンドポイントに渡されていないにもかかわらず、 に org_id クレームが含まれている場合、アプリケーションはそのクレームを検証し、受信した値が想定どおりまたは既知のものであり、有料顧客など、アプリケーションが信頼するエンティティに対応していることを確認する必要があります。クレームを検証できない場合、アプリケーションはそのトークンを無効と見なす必要があります。 API の場合: アクセストークンに org_id クレームが含まれている場合、API はそのクレームを検証し、受信した値が想定どおりまたは既知のものであり、有料顧客など、アプリケーションが信頼するエンティティに対応していることを確認する必要があります。クレームを検証できない場合、API はそのトークンを無効と見なす必要があります。 特に、次の点を確認してください。
  • iss (issuer) クレームを確認し、トークンが Auth0 によって発行されたことを確かめる必要があります。
  • org_id クレームを確認し、それがアプリケーションですでに認識されている値であることを確かめる必要があります。これは、既知の組織 ID の一覧と照合して検証することも、現在のリクエスト URL と組み合わせて確認することもできます。たとえば、サブドメインから、IDトークンの検証時にどの組織を使用すべきかを判断できる場合があります。
通常は、issuer のみを検証すれば、そのトークンが Auth0 によって発行されたことを確認するには十分です。ただし、組織を使用する場合は、Auth0 テナント内の組織が想定どおりのものであることを確認するために、追加の検証を行う必要があります。 また、API サーバーが org_id に基づいてデータやリソースへのアクセスを分離することも非常に重要です。これにより、アクセストークンで特定の組織に対応する org_id 値を受信した場合、その組織に関する情報だけにアクセスまたは変更できることが保証されます。

​
詳細情報