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

# シングルIDプロバイダー：認可

> 複数テナントのアーキテクチャでユーザーを認可することについて説明します。

認可では通常、誰に何が許可されるのかをどのようにして決定するのか、そして、この許可に関する情報をどのようにしてアプリケーションやAPIに伝えるのかを考える必要があります。使用しているアプリケーションによっては、それらの片方または両方の影響を受けることがあります。当社のアーキテクチャシナリオでは、[B2B認可](/docs/ja-JP/ja-jp/get-started/architecture-scenarios/business-to-business/authorization)に関する一般的なガイダンスを提供しています。こちらのガイダンスと併せて確認することをお勧めします。

* [IDトークン](/docs/ja-JP/ja-jp/secure/tokens/id-tokens)は一般的に、カスタムクレームを使って、ユーザーの認可情報をアプリケーションへ伝えるために使用されます。このカスタムクレームは[ルール](/docs/ja-JP/ja-jp/customize/rules)拡張を使って追加することができます。追加されたクレームは、ユーザーの許可されていない操作を阻止するユーザーインターフェイスを表示できるようにします。また、IDトークンの認可情報は、ユーザーが従来型のWebアプリでフロントエンドの制御を迂回できないようにする方法をアプリケーションのバックエンドに提供します。

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

  アクセス権限は、[Auth0 Authorization Core](/docs/ja-JP/ja-jp/manage-users/access-control/configure-core-rbac)機能経由で[Auth0 Role-Based Access Control](/docs/ja-JP/ja-jp/manage-users/access-control/rbac)（RBAC）を使用して定義し、アクセストークンに自動的に適用することができます。詳細については、「[APIのRole-Based Access Control（RBAC）を有効にする](/docs/ja-JP/ja-jp/get-started/apis/enable-role-based-access-control-for-apis)」を参照してください。

  Auth0のRBAC機能から提供された情報をIDトークンに（手動で適用する場合はアクセストークンにも）カスタムクレームとして追加することもできます。Auth0 Organizationsは、メンバーシップを通じて割り当てられたロールを介してAuth0 RBAC機能を活用することができます。詳細については、「[Organazaionメンバーにロールを追加する](/docs/ja-JP/ja-jp/manage-users/organizations/configure-organizations/add-member-roles)」を参照してください。
</Callout>

* 共有リソースサービスへの公開アクセスを提供するAPIは通常、アクセス制御メカニズムによって保護されます。このため、Auth0には認可ベアラートークンまたは<Tooltip data-tooltip-id="react-containers-DefinitionTooltip-0" href="/docs/ja-JP/ja-jp/glossary?term=oath2" tip="OAuth 2.0: 認可プロトコルとワークフローを定義する認可フレームワーク。" cta="用語集の表示">OAuth</Tooltip> 2[アクセストークン](/docs/ja-JP/ja-jp/secure/tokens/access-tokens)を作成する機能が備わっており、これでユーザー認可情報をAPIに伝えることができます。通常は、Auth0の[Role-Based Access Control (RBAC)](/docs/ja-JP/ja-jp/manage-users/access-control/configure-core-rbac)を使用して1つ以上の[メンバーシップが割り当てられたロール](/docs/ja-JP/ja-jp/manage-users/organizations/configure-organizations/add-member-roles)を適用するか、[ルール](/docs/ja-JP/ja-jp/customize/rules)拡張を介してカスタムクレームを追加することで実行されます。Auth0のRBAC機能を活用して、アクセストークンの`スコープ`クレームを自動的に調整することもできます。APIはこの情報を使って適切なレベルのアクセス制御を適用し、ユーザーについての情報を追加で検索することなく、ポリシールールを適用できるようにします。
* Auth0テナントでアプリケーションレベルのポリシーを実装したい場合には、広範囲のアプリケーションやリソースサービス（API）にポリシーを適用できるようになります。個別に変更する必要はありません。これを実装するには通常、[ルール](/docs/ja-JP/ja-jp/customize/rules)拡張を使用します。

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

  Auth0 Organizationsは、ユーザーの認証時にAuth0ルールが組織中心の情報にアクセスできるようにします。この情報には、ルールの`context`オブジェクトに含まれている`organization`オブジェクトを介してアクセスします。`organization`オブジェクトは、Auth0のOrganization定義に照らし合わせてプロビジョニングされたメタデータへのアクセスも可能にします。詳細については、「[Organizationのカスタム開発](/docs/ja-JP/ja-jp/manage-users/organizations/custom-development)」を参照してください。
</Callout>

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

通常、クレームは[IDトークンクレーム](/docs/ja-JP/ja-jp/get-started/architecture-scenarios/business-to-consumer/authorization)のベストプラクティスガイドに説明されるように、IDトークンに追加することができます。Auth0組織機能を使用する場合、`org_id`クレームは組織メンバーシップを持つユーザーに発行された任意のIDトークン（例については、「[トークンと組織を使用する](/docs/ja-JP/ja-jp/manage-users/organizations/using-tokens)」を参照）に自動的に追加されます。このパラメーターはAuth0 SDKが検証します。また、IDトークンにカスタムクレームを追加して、Auth0の組織に関連付けられた補足情報を追加することもできます。

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

**注意** :Authentication APIで組織名が使用できるようにテナントを構成した場合には、`org_name`クレームがIDトークンに自動的に含まれます。詳細については、「[Authentication APIでOrganization名を使用する](/docs/ja-JP/ja-jp/manage-users/organizations/configure-organizations/use-org-name-authentication-api) 」を参照してください。

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

Auth0 Organizations（組織）機能は 、<Tooltip data-tooltip-id="react-containers-DefinitionTooltip-1" href="/docs/ja-JP/ja-jp/glossary?term=security-assertion-markup-language" tip="Security Assertion Markup Language（SAML）: パスワードなしに二者間で認証情報を交換できる標準化プロトコル。" cta="用語集の表示">SAML</Tooltip>対応のアプリケーションには対応していませんが、アップストリームのIDプロバイダー（<Tooltip data-tooltip-id="react-containers-DefinitionTooltip-2" href="/docs/ja-JP/ja-jp/glossary?term=idp" tip="IDプロバイダー（IdP）: デジタルIDを保存および管理するサービス。" cta="用語集の表示">IdP</Tooltip>）が生成したSAMLアサーションを構成して、ダウンストリームで使用されるIDトークンに標準やカスタムのクレームを追加することはできます。たとえば、以下のように、SAMLエンタープライズ接続にあるマッピングセクションを定義することができます。

```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"
}
```

この例では、各フィールドにルールの`user`オブジェクト内の値が割り当てられ、IDトークンの標準クレームにマッピングするか、カスタムクレームを使ってマッピングされます。SAMLマッピングをカスタマイズする方法の詳細については、「[アプリをSAML IDプロバイダーに接続する：マッピングをセットアップする](/docs/ja-JP/ja-jp/connections/enterprise/saml#set-up-mappings)」を参照してください。

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

アクセス制御を決定する上でアクセストークンに追加するその他のクレームに加えて（[アクセストークンのクレーム](/docs/ja-JP/ja-jp/get-started/architecture-scenarios/business-to-consumer/authorization)のベストプラクティスに関する一般的なガイダンスを参照）、通常は、ユーザーが属する組織にも伝えるようにしましょう。

IDトークンと同様に、Auth0組織機能を使用する場合、`org_id`クレームは組織メンバーシップを持つユーザーに発行された任意のアクセストークン（例については、「[トークンと組織を使用する](/docs/ja-JP/ja-jp/manage-users/organizations/using-tokens)」を参照）に自動的に追加されます。また、アクセストークンにカスタムクレームを追加して、Auth0の組織に関連付けられた補足情報を追加することもできます。

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

**注意** :Authentication APIで組織名が使用できるようにテナントを構成した場合には、`org_name`クレームがアクセストークンに自動的に含まれます。詳細については、「[Authentication APIでOrganization名を使用する](/docs/ja-JP/ja-jp/manage-users/organizations/configure-organizations/use-org-name-authentication-api) 」を参照してください。

または、各組織に一意のAPIオーディエンスを作成することもできます。そうすると、APIの定義がAuth0で一意のものになります。この方法では、カスタムのルール拡張を取り入れる必要がなくなりますが、複雑性が伴うため、困難になるかもしれません。以下の表は簡単な比較をまとめたものです。

<table class="table">
  <thead>
    <tr>
      <th><strong>手法</strong></th>
      <th><strong>長所</strong></th>
      <th><strong>短所</strong></th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>一意のAPIオーディエンス</td>
      <td><ul><li>1つの組織におけるM2Mアクセスの対応がそのままで便利に使用できる。</li><li>オーディエンスはアクセストークン内の標準クレーム</li><li>リフレッシュトークンの処理が組織のロジックを追加で必要としない</li></ul></td>
      <td><ul><li>各組織にAPIを自動作成する必要がある</li><li>RBACの使用では、独立したロールを作成する必要があるかもしれない</li>メンバーシップにロールを自動でプロビジョニングしなければならない<li>APIの実装が複数のオーディエンスを処理しなければならない</li></ul></td>
    </tr>

    <tr>
      <td>カスタムクレーム</td>
      <td>Auth0テナントの構成を簡素化する</td>
      <td>トークンにアクセスする組織を追加するには、ルール内にカスタムコードがなければならない</td>
    </tr>
  </tbody>
</table>

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

Auth0組織機能は、Auth0テナントに関連する[認可コア](/docs/ja-JP/ja-jp/manage-users/access-control/configure-core-rbac)機能を使用して、[Role-Based Access Control (RBAC)](/docs/ja-JP/ja-jp/manage-users/access-control/rbac)もサポートします。RBACは、[Auth0組織のメンバーシップレベルで適用](/docs/ja-JP/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/ja-jp/get-started/apis/enable-role-based-access-control-for-apis)すると、アクセストークンに含まれるデフォルトの`scope`クレームが自動的に変更され、`permission`クレームがデフォルトで追加されます（例については「[トークンとOrganizationでの作業](/docs/ja-JP/ja-jp/manage-users/organizations/using-tokens)」を参照してください）。また、ロール情報をカスタムクレームとしてIDトークンに追加することもできます。それには、ルールの `context`オブジェクトにある`authorization`オブジェクトにアクセスします。詳細については、「[認可でのルールのサンプルユースケース：ユーザーのロールをトークンに追加する](/docs/ja-JP/ja-jp/manage-users/access-control/sample-use-cases-rules-with-authorization)」を参照してください。
</Callout>

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

リソースレベルのポリシーを適用することは、システムにあるアプリケーションとAPIの責任です。Auth0テナントなど、中央集中型の認可サーバーでポリシーの適用を管理しようとすると、制御システムが複雑になり、維持と理解が難しいという問題に直面することになります。そこで代わりに、ユーザーについての適切な情報がトークンに確実に含まれていことを中央集中型の認可サーバーが管理して、アプリケーションやAPIがポリシーの適用を決めるのに必要な情報を持っているようにします。少なくとも、1つのトークンに含めるには情報が多すぎる（リソースレベルの許可など）か、情報が頻繁に変わるため、直接アクセスしたトークンの情報が古くなっている場合には、アプリケーションやAPIが正しい情報を検索する必要があります。

一方で、大体のポリシーは中央管理で適用することができます。たとえば、Auth0テナントの場合、すべてのアプリケーションやAPIに同じ制約を適用しなくてもいいように、ルールを実装できるような状況もあります。それらの状況には以下が挙げられます。

* 特定のIPアドレスからのユーザーアクセスを阻止する
* Contextual <Tooltip data-tooltip-id="react-containers-DefinitionTooltip-0" href="/docs/ja-JP/ja-jp/glossary?term=multifactor-authentication" tip="多要素認証（MFA）: ユーザー名とパスワードに加えて、SMS経由のコードなどの要素を使用するユーザー認証プロセス。" cta="用語集の表示">MFA</Tooltip>や<Tooltip data-tooltip-id="react-containers-DefinitionTooltip-4" href="/docs/ja-JP/ja-jp/glossary?term=adaptive-multi-factor-authentication" tip="Adaptive Multifactor Authentication: ログイン試行が信頼性の低いログインであると判断された場合にのみ、ユーザーに対してトリガーされる多要素認証（MFA）。" cta="用語集の表示">Adaptive MFA</Tooltip>に固有の要件を実装する
* メールアドレスが確認されたユーザーのみにログインを制限する
* 特定のAPIオーディエンスへのアクセスを制限する。これによって、ユーザーがアクセストークンを取得できるAPIオーディエンスが限られるか、ユーザーがオーディエンスからアクセストークンを取得できる状況が制限される。このとき、各組織にカスタムAPIオーディエンスを作成している場合には、認証しているユーザーの組織がAPIオーディエンスの組織と一致していることを、ルールで保証しなくてはなりません。

<Warning>
  Auth0 Management APIへのアクセスは、組織によって制限されません。Auth0 Management APIへのアクセスは、マシンツーマシンのコンテキストで使用するために割り当てられたアクセストークンを介して行われ、Auth0 Organizationによって制限されることはありません。そのため、顧客にはAuth0 Management APIのインスタンスに直接アクセスする権限を与えないでください。顧客がユーザーアカウントなどの組織の側面を管理しなければならない場合（「[プロファイル管理](/docs/ja-JP/ja-jp/get-started/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/profile-management)」を参照）は、その目的のために独自の独立したアプリケーションまたはAPIをビルドする必要があります。
</Warning>