利用可能性はAuth0プランによって異なる
この機能が利用できるかどうかは、ご利用のAuth0プラン(または契約)によります。詳細については、「価格設定」をお読みください。
name
クレームが含まれています。
JWTクレームには以下の2種類があります。
- 登録済み :サードパーティまたは外部のアプリケーションとの相互運用性を確保するためにJWT仕様で定義されたクレーム。OpenID Connect(OIDC)標準クレームは予約済みクレームです。
- カスタム :独自に定義したクレーム。未登録で衝突耐性のあるパブリッククレームか、または衝突の可能性がある未登録で非公開のプライベートクレームである可能性があります。予約済みクレームや他のカスタムクレームとの衝突を避けるため、名前空間などを使用してこれらのクレームに慎重に名前を付けてください。同じ名前で異なる情報のある2つのクレームを扱うことは困難な場合があります。
組織を通してユーザーを認証する
組織を通じてユーザーを認証するには、/authorize
エンドポイントへの呼び出しにorganization
パラメーターが追加されます。以下は、ユーザーが組織を通してログインした際に返されるトークンの例です。
IDトークンとアクセストークンには、デフォルトでOrganization IDのみが含まれます。ただし、テナントは、Authentication APIでOrganization名を使用できるように構成することも可能です。そのように構成すると、IDトークンとアクセストークンに
org_id
クレームとorg_name
クレームの両方が含まれるようになります。詳細については、「Authentication APIでOrganization名を使用する 」を参照してください。IDトークン
次の例では、https://marketplace/roles
とhttps://namespace.exampleco.com/
はトークンに追加されたカスタムクレームであり、含まれている他のクレームは標準クレームであることに注意してください。
アクセストークン
組織へのマシンツーマシンアクセス
マシンツーマシンのユースケースでは、/oauth/token
エンドポイントへのクライアント資格情報要求にorganization
パラメーターが追加され、アプリケーションはユーザーではなく自分自身のアクセストークンを取得できます。
IDトークンとアクセストークンには、デフォルトでOrganization IDのみが含まれます。ただし、テナントは、Authentication APIでOrganization名を使用できるように構成することも可能です。そのように構成すると、IDトークンとアクセストークンに
org_id
クレームとorg_name
クレームの両方が含まれるようになります。詳細については、「Authentication APIで組織名を使用する」をお読みください。トークンを検証する
/authorize
エンドポイントまたは/oauth/token
エンドポイントへの呼び出しにorganization
パラメーターが追加されると、Auth0 SDKはorg_id
クレームを自動的に検証し、生成されたトークンの一部として返します。ただし、セキュリティを保護するために、追加の検証はトークンを受け取ったときに行います。
テナントの構成を通じてAuthentication APIにおけるOrganization名の使用を許可した場合は、IDトークンとアクセストークンに
org_id
クレームとorg_name
クレームの両方が含まれます。その場合は、org_id
クレームに加えてorg_name
クレームも検証し、受け取った値が信頼できるエンティティと一致することを確認します。一般に、トークンの検証にはOrganization IDを使用することが推奨されます。ただし、Organization名の方が適している状況では、Organization名を使用してかまいません。トークンの検証にOrganization名を使用をした場合の影響については、「Authentication APIでOrganization名を使用する」をお読みください。/authorize
エンドポイントにorganization
パラメーターが渡されなかったけれど、IDトークンにorg_id
クレームが存在する場合、アプリケーションはクレームを検証して、受け取った値が予期されるか既知であること、および支払いを行う顧客など、アプリケーションが信頼するエンティティに対応していることを保証します。クレームが検証できない場合には、アプリケーションはトークンが無効であると判断します。
API
org_id
クレームがある場合には、APIがクレームを検証して、受け取った値が既知または予期されたものであり、アプリケーションが信頼するエンティティ(顧客など)に対応していることを保証します。クレームが検証できない場合には、APIはトークンが無効であると判断します。
特に:
iss
(発行者)クレームがAuth0によって発行されたトークンであることを確認する必要があります。org_id
クレームの値がアプリケーションに既知の値であることを確認する必要があります。これは、組織IDの既知リストに照らし合わせて検証することができます。あるいは、現在の要求のURLと併せて確認できるかもしれません。たとえば、IDトークンを検証する際に、どの組織を使用するべきなのかをサブドメインが示唆することもあります。
org_id
に基づいてデータとリソースへのアクセスをセグメント化することも非常に重要です。これにより、アクセストークンで指定された組織に対応するorg_id
値を受け取ったときに、その組織に関する情報のみにアクセスしたり変更したりできるようになります。