> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> マルチテナント アーキテクチャにおける Organizations のユーザー認可について学びます。

# Single Identity Provider: 認可

認可について考える際には、通常、「ユーザーに何が許可されているかをどのように判断するか」と、「その情報をアプリケーションや API にどう伝えるか」を検討する必要があります。利用しているアプリケーションによっては、これらのどちらか一方、または両方が関係します。このアーキテクチャ シナリオでは、ここで説明するガイダンスとあわせて確認することをお勧めする、汎用的な [B2B Authorization](/docs/ja-jp/get-started/architecture-scenarios/business-to-business/authorization) のガイダンスも提供しています。

* [ID トークン](/docs/ja-jp/secure/tokens/id-tokens) は、カスタムクレームを通じてユーザーの認可情報をアプリケーションに伝えるためによく使われます。これらのクレームは、[ルール](/docs/ja-jp/customize/rules) の拡張機能を使って追加できます。クレームを追加することで、ユーザーが権限のない操作を試せないようなユーザー インターフェースを提供できます。<Tooltip tip="ID トークン: リソースへのアクセス用ではなく、クライアント自身のためのクレデンシャルです。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=ID+Token">ID トークン</Tooltip> に含まれる認可情報は、従来型の web app において、ユーザーがフロントエンドの制御を回避することを防ぐための手段を、アプリケーションのバックエンドにも提供します。

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  **ベストプラクティス**

  [Auth0 ロールベースのアクセス制御](/docs/ja-jp/manage-users/access-control/rbac) (RBAC) を [Auth0 Authorization Core](/docs/ja-jp/manage-users/access-control/configure-core-rbac) 機能で利用して、アクセス権限を定義できます。これらの権限はアクセストークンに自動的に適用できます。詳細については、[API で Auth0 Authorization Core RBAC を有効にする](/docs/ja-jp/get-started/apis/enable-role-based-access-control-for-apis) を参照してください。

  Auth0 RBAC 機能では、ID トークンにカスタムクレームとして追加できる情報も提供できます (必要に応じて手動で適用する場合は、アクセストークンにも追加できます) 。Auth0 Organizations では、メンバーシップに割り当てられた 1 つ以上のロールを通じて、Auth0 RBAC 機能を活用できます。詳しくは、[Add Roles to Organization Members](/docs/ja-jp/manage-users/organizations/configure-organizations/add-member-roles) を参照してください。
</Callout>

* 共有リソース サービスへの公開アクセスを提供する API は、通常、アクセス制御の仕組みによって保護されます。この目的のために、Auth0 では認可用の bearer token、つまり <Tooltip tip="OAuth 2.0: 認可プロトコルとワークフローを定義する認可フレームワークです。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=OAuth">OAuth</Tooltip> 2 の [アクセストークン](/docs/ja-jp/secure/tokens/access-tokens) を作成できます。これにより、通常は Auth0 の [ロールベースのアクセス制御 (RBAC)](/docs/ja-jp/manage-users/access-control/configure-core-rbac) を使って 1 つ以上の[メンバーシップに割り当てられたロール](/docs/ja-jp/manage-users/organizations/configure-organizations/add-member-roles) を適用したり、[ルール](/docs/ja-jp/customize/rules) の拡張機能を通じてカスタムクレームを追加したりすることで、API にユーザーの認可情報を伝えられます。また、Auth0 RBAC 機能を利用して、<Tooltip tip="アクセストークン: API へのアクセスに使用される、不透明な文字列または JWT 形式の認可クレデンシャルです。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=access+token">アクセストークン</Tooltip> の `scope` claim を自動的に調整することもできます。API はこの情報を使って適切なレベルのアクセス制御を適用できるため、ユーザー情報を取得するための追加の参照を行わなくても、ポリシー ルールを強制できます。
* 特定のケースでは、Auth0 テナントでアプリケーション レベルのポリシーを実装したいことがあります。これにより、各アプリケーションやリソース サービス (API) を個別に変更しなくても、幅広いアプリケーションやリソース サービスにポリシーを適用できます。通常、これは [ルール](/docs/ja-jp/customize/rules) の拡張機能を使って実装します。

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  **ベストプラクティス**

  Auth0 Organizations は、ユーザーの認証時に参照できる organization 中心の情報を Auth0 ルールに提供します。この情報は、ルール の `context` object に含まれる `organization` object から利用できます。`organization` object では、Auth0 の Organization 定義に対してプロビジョニングされた任意のメタデータにもアクセスできます。詳しくは、[Custom Development for Organizations](/docs/ja-jp/manage-users/organizations/custom-development) を参照してください。
</Callout>

<div id="id-token-claims">
  ## ID トークンのクレーム
</div>

通常、クレームは [ID Token Claims](/docs/ja-jp/get-started/architecture-scenarios/business-to-consumer/authorization) のベストプラクティス ガイダンスで説明されているとおり、ID トークンに追加できます。Auth0 Organizations 機能を使用すると、organization のメンバーシップを持つユーザー向けに発行されるすべての ID トークンに `org_id` クレームが自動的に追加されます (例については、[Tokens と Organizations を扱う](/docs/ja-jp/manage-users/organizations/using-tokens) を参照してください) 。このパラメーターは Auth0 SDK によって検証されます。また、ID トークンにカスタムクレームを追加することで、Auth0 Organization に関連付けられた追加情報を含めることもできます。

```js wrap lines theme={null}
context.idToken['http://travel0.net/multifactor'] = context.multifactor;
```

**注**: tenant を Authentication API で organization名をサポートするように設定している場合、`org_name` claim は ID トークンに自動的に含まれます。詳しくは、[Use Organization Names in Authentication API](/docs/ja-jp/manage-users/organizations/configure-organizations/use-org-name-authentication-api) を参照してください。

<div id="saml-assertion">
  ### SAML アサーション
</div>

上流の IDプロバイダー (IdP) によって生成された <Tooltip tip="Security Assertion Markup Language (SAML): パスワードなしで 2 者間が認証情報を交換できるようにする標準化されたプロトコル。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=SAML">SAML</Tooltip> アサーションは、下流で使用される ID トークンに標準クレームまたはカスタムクレームを設定するよう構成できます。

たとえば、SAML エンタープライズ接続の mappings セクションを定義できます。

```json lines theme={null}
{ 
  "user_id": [
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn",
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
  ],
  "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
  "name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
  "given_name": [
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
  ], 
  "family_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname",
  "groups": "http://schemas.xmlsoap.org/claims/Group"
}
```

この例では、各フィールドには Action 内の `user` オブジェクトで値が割り当てられ、その値は ID トークン内の標準クレームにマッピングされるか、[カスタムクレーム](/docs/ja-jp/secure/tokens/json-web-tokens/json-web-token-claims#custom-claims)を使用してマッピングできます。SAML マッピングのカスタマイズについて詳しくは、[アプリをSAML IDプロバイダーに接続する: マッピングを設定する](/docs/ja-jp/authenticate/identity-providers/enterprise-identity-providers/saml#set-up-mappings)を参照してください。

アプリケーションで SAML を使用し、Auth0 が IdP として機能する場合は、organization クエリパラメータを使用して、SAML サインインリクエストに [組織](/docs/ja-jp/manage-users/organizations) を含めることができます。

```js wrap lines theme={null}
https://{YOUR_AUTH0_DOMAIN}/samlp/{YOUR_APP_CLIENT_ID}?organization={YOUR_ORGANIZATION_ID}
```

Auth0 は、SAML レスポンス内で organization をカスタム属性として返します。

```js wrap lines theme={null}
http://schemas.auth0.com/org_id
```

Action で設定されたカスタムクレームなど、OIDC トークンに含まれる非標準クレームも、`http://schemas.auth0.com/` をプレフィックスとして SAML レスポンスに含まれます。

<div id="access-token-claims">
  ## アクセストークンのクレーム
</div>

アクセス制御の判断のためにアクセストークンに追加する他のクレームに加えて (一般的な[アクセストークンのクレーム](/docs/ja-jp/get-started/architecture-scenarios/business-to-consumer/authorization)に関するベストプラクティスのガイダンスを参照) 、通常は、ユーザーが属している organization も伝える必要があります。

ID トークンと同様に、Auth0 Organizations 機能を使用する場合、organization のメンバーシップを持つユーザー向けに発行されるすべてのアクセストークンには、`org_id` クレームが自動的に追加されます (例については、[Tokens と Organizations を扱う](/docs/ja-jp/manage-users/organizations/using-tokens)を参照してください) 。また、アクセストークンにカスタムクレームを追加することで、Auth0 Organization に関連付けられた追加情報を含めることもできます。

```js wrap lines theme={null}
context.accessToken['http://travel0.net/multifactor'] = context.multifactor;
```

**注**: テナントを Authentication API で organization名をサポートするように設定している場合、`org_name` クレームはアクセストークンに自動的に含まれます。詳しくは、[Use Organization Names in Authentication API](/docs/ja-jp/manage-users/organizations/configure-organizations/use-org-name-authentication-api)を参照してください。

または、organization ごとに一意の API <Tooltip tip="Audience: 発行されたトークンの audience の一意な識別子。トークン内では aud という名前で、その値には ID トークンのアプリケーション（Client ID）またはアクセストークンの API（API 識別子）のいずれかの ID が含まれます。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=audience">audience</Tooltip> を作成することもできます。これにより、Auth0 で一意の API 定義が作成されます。この方法では、カスタム ルール による拡張の必要性を抑えられますが、その一方で複雑さが増し、扱いが難しくなることがあります。簡単に比較すると次のとおりです。

| Approach            | Pros                                                                                                                                                                     | Cons                                                                                                                                                                                                        |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Unique API Audience | <ul><li>単一の organization に対する machine-to-machine access を標準でサポートします。</li><li>audience はアクセストークンの標準クレームです。</li><li>リフレッシュトークンの処理に追加の organization ロジックは必要ありません。</li></ul> | <ul><li>organization ごとに API を作成する処理を自動化する必要があります。</li><li>ロールベースのアクセス制御を使用する場合は、個別の Roles を作成する必要が生じることがあります。</li>Roles からメンバーシップへのプロビジョニングを自動化する必要があります。<li>API 実装では複数の audience を処理しなければなりません。</li></ul> |
| Custom Claim        | Auth0 テナントの設定を簡素化できます。                                                                                                                                                   | organization をアクセストークンに追加するには、ルール内でカスタムコードが必要です。                                                                                                                                                            |

<div id="roles">
  ### ロール
</div>

Auth0 Organizations 機能は、Auth0 テナントに関連付けられた [Authorization Core](/docs/ja-jp/manage-users/access-control/configure-core-rbac) 機能を通じて、[ロールベースのアクセス制御 (RBAC)](/docs/ja-jp/manage-users/access-control/rbac) もサポートしています。RBAC は、[Auth0 Organization のメンバーシップ レベルで適用されます](/docs/ja-jp/manage-users/organizations/configure-organizations/add-member-roles)。

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  [API で Auth0 Authorization Core RBAC を有効にする](/docs/ja-jp/get-started/apis/enable-role-based-access-control-for-apis)ことができます。これにより、アクセストークン内のデフォルトの `scope` クレームが自動的に変更され、デフォルトで `permission` クレームも追加されます (例については、[Tokens と Organizations を扱う](/docs/ja-jp/manage-users/organizations/using-tokens)を参照してください) 。また、ルール の `context` オブジェクトで使用できる `authorization` オブジェクトにアクセスして、ロール情報をカスタムクレームとして ID トークンに追加することもできます。詳しくは、[Authorization を使用するルールのサンプルユースケース: トークンにユーザー ロールを追加する](/docs/ja-jp/manage-users/access-control/sample-use-cases-rules-with-authorization)を参照してください。
</Callout>

<div id="access-control">
  ## アクセス制御
</div>

リソースレベルのポリシー適用は、システム内のアプリケーションおよび/または API が担うべきものです。Auth0 テナントのような集中型の<Tooltip tip="認可サーバー: ユーザーのアクセス範囲の境界を定義するうえで役割を果たす集中型サーバー。たとえば、認可サーバーはユーザーが利用できるデータ、タスク、機能を制御できます。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Authorization+Server">認可サーバー</Tooltip>でポリシーを適用しようとすると、保守や理解が難しい複雑な制御システムにすぐ行き着いてしまいます。そうするのではなく、集中型の認可サーバーは、ユーザーに関する適切な情報がトークンに含まれるようにすることで、アプリケーションや API がポリシー適用の判断に必要な情報を得られるようにできます。少なくとも、1 つのトークンに収めるには情報量が多すぎる場合 (たとえば、リソースレベルの permissions) や、情報の更新頻度が高く、トークンから直接参照すると古くなってしまう場合には、アプリケーションや API が正しい情報を参照できるようにしておく必要があります。

一方で、より大枠のポリシー適用の一部は、集中型で処理することもできます。たとえば、Auth0 テナントのコンテキストを使用している場合、すべてのアプリケーションおよび/または API が同じ制限を適用しなくても済むようにする ルール を実装できるケースがあります。具体的には、次のようなものです。

* 特定の IP アドレスからのユーザーアクセスをブロックする
* コンテキストに応じた要件や <Tooltip tip="Adaptive Multi-factor Authentication: 試行された login が信頼性の低い login だと判断された場合にのみ、ユーザーに対してトリガーされる多要素認証 (MFA)。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Adaptive+MFA">Adaptive MFA</Tooltip> に関する特定の要件を実装する
* メールアドレスを確認済みのユーザーのみにログインを制限する
* 特定の API audience へのアクセスを制限し、ユーザーがほかの API audience 用のアクセストークンを取得できないようにする、または特定の状況ではその audience 用のアクセストークンを取得できないようにする。この場合、各 organization ごとにカスタム API Audience を作成しているなら、対応する API audience に一致する organization に認証中のユーザーが所属していることも、ルール で保証する必要があります。

<Warning>
  Auth0 Management API へのアクセスは organization によって制限されません。Auth0 Management API へのアクセスは machine-to-machine コンテキストで使用するために割り当てられたアクセストークンを介して行われ、Auth0 Organization によって制約することはできません。したがって、お客様に Auth0 Management API のインスタンスへの直接アクセスを提供しないでください。お客様がユーザーアカウントなど organization の一部を管理する必要がある場合 ([プロファイル管理](/docs/ja-jp/get-started/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/profile-management) を参照) 、この目的のために独自のアプリケーションおよび/または API を構築する必要があります。
</Warning>